RPKI Signed Object for Trust Anchor Key
LACNIC
Rambla Mexico 6125
Montevideo
11400
Uruguay
carlos@lacnic.net
https://www.lacnic.net/
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane
4101
Australia
QLD
ggm@apnic.net
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane
4101
Australia
QLD
tomh@apnic.net
RIPE NCC
Stationsplein 11
Amsterdam
- The OID (in ) that identifies the signed object as being a TAK. (This OID
appears within the eContentType in the encapContentInfo object, as well as the content-type
signed attribute in the signerInfo object.)
- The ASN.1 syntax for the TAK eContent, in .
- The additional steps required to validate a TAK, in
.
The TAK Object Content Type
This document specifies an OID for the TAK object as follows:
This OID MUST appear in both the eContentType in the encapContentInfo
object and the content-type signed attribute in the signerInfo
object (see ).
The TAK Object eContent
The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER)
, and is defined per the module in .
TAKey
This structure defines a TA public key, similar to that from . It contains a sequence of zero or more comments, one or more certificate URIs, and a
SubjectPublicKeyInfo.
- comments: This field is semantically equivalent to the comment section defined in section 2.2 of
. Each comment is
human-readable informational UTF-8 text , conforming to the
restrictions defined in Section 2 of . The leading "#" character that is used to
denote a comment in is
omitted here.
- certificateURIs: This field is semantically equivalent to the URI section defined in section 2.2 of
. It MUST
contain at least one CertificateURI element. Each CertificateURI element contains the IA5String
representation of either an rsync URI
, or an HTTPS URI
.
- subjectPublicKeyInfo: This field contains a SubjectPublicKeyInfo (section 4.1.2.7 of
) in DER format
.
TAK
- version: The version number of the TAK object MUST be 0.
- current: This field contains the TA public key of the repository in
which the TAK object is published.
- predecessor: This field contains the TA public key that was in use
for this TA immediately prior to the current TA public key, if
applicable.
- successor: This field contains the TA public key to be used in place of
the current public key, if applicable, after expiry of the relevant acceptance
timer.
TAK Object Validation
To determine whether a TAK object is valid, the RP MUST perform the
following checks in
addition to those specified in
:
- The eContentType OID matches the OID described in
.
- The TAK object appears as the product of a TA CA
certificate (i.e. the TA CA certificate is itself the issuer
of the End-Entity (EE) certificate of the TAK object).
- The TA CA has published only one TAK object in its
repository for this public key, and this
object appears on the manifest as the only entry using the ".tak" extension (see
).
- The EE certificate of this TAK object describes its Internet Number Resources (INRs) using
the "inherit" attribute.
- The decoded TAK content conforms to the format defined in
.
- The SubjectPublicKeyInfo value of the current TA public key in the
TAK object matches that of the TA CA certificate used to issue
the EE certificate of the TAK object.
If any of these checks does not succeed, the RP MUST ignore the TAK
object and proceed as though it were not listed on the manifest.
The RP is not required to compare its current set of
certificateURIs for the current public key with those listed in the TAK
object. The RP MAY alert the user that these sets of certificateURIs do
not match, with a view to the user manually updating the set
of certificateURIs in their configuration. The RP MUST NOT
automatically update its configuration to use these
certificateURIs in the event of inconsistency, though, because
the migration of users to new certificateURIs should
happen by way of the successor public key process.
TAK Object Generation and Publication
A non-normative guideline for naming this object is that the
filename chosen for the TAK
object in the publication repository be a value derived from the public key part of the entity's
key pair, using the algorithm described for CRLs in section 2.2 of
for generation
of filenames. The filename extension of ".tak" MUST be used to denote the object as a TAK.
In order to generate a TAK object, the TA MUST perform the following actions:
- The TA MUST generate a one-time-use EE certificate for the TAK.
- This EE certificate MUST have a unique key pair.
- This EE certificate MUST have a Subject Information Access
(SIA) extension access description field with an
accessMethod OID value of id-ad-signedObject, where the associated accessLocation
references the publication point of the TAK as an object URL.
- As described in
, the EE certificate used for
this object must include an
extension. However, because the resource set is irrelevant to this object type, this
certificate MUST describe its Internet Number Resources (INRs) using the "inherit" attribute,
rather than explicitly describing a resource set.
- This EE certificate MUST have a "notBefore" time that matches or predates the moment that
the TAK will be published.
- This EE certificate MUST have a "notAfter" time that reflects the intended duration for which
this TAK will be published. If the EE certificate for a TAK object is expired, it MUST no longer
be published, but it MAY be replaced by a newly generated TAK object with equivalent
content and an updated "notAfter" time.
- The current TA public key for the TAK MUST match that of the TA CA
certificate under which the TAK was issued.
In distribution contexts that support media types, the
"application/rpki-signed-tal" media type can be used for TAK
objects.
Relying Party Use
Relying Parties MUST keep a record of the current public key for each
configured TA, as well as the URI(s) where the CA certificate for this
public key may be retrieved. This record is typically bootstrapped by the use of a pre-configured (and unsigned) TAL file
.
When performing top-down validation, RPs MUST first validate and
process the TAK object for its current known public key, by performing the following steps:
- A CA certificate is retrieved and validated from the known URIs as described in
sections 3 and 4 of
.
- The manifest and CRL for this certificate are then validated as described
in
and
.
- The TAK object, if present, is validated as described in
.
If the TAK object includes a successor public key, then the RP must
verify the successor public key by doing the following:
- performing top-down validation using the
successor public key, in order to validate the TAK object for the
successor TA;
- ensuring that a valid TAK object exists for the successor
TA;
- ensuring that the successor TAK object's current public key matches the
initial TAK object's successor public key; and
- ensuring that the successor TAK object's predecessor
public key matches
the initial TAK object's current public key.
If any of these steps fails, then the successor public key has failed
verification.
If the successor public key passes verification, and the RP has not
seen that successor public key on the previous successful validation
run for this TA, then the RP:
- sets an acceptance timer of 30 days for this
successor public key for this TA;
- cancels the existing acceptance timer for this TA (if
applicable); and
- continues standard top-down validation as
described in using the
current public key.
If the successor public key passes verification, and the RP has seen
that successor public key on the previous successful validation run for
this TA:
- if the relevant acceptance timer has not
expired, the RP continues standard top-down validation using
the current public key;
- otherwise, the RP updates its current known
public key details for this TA to be those of the successor
public key, and then begins
top-down validation again using the successor public key.
If the successor public key does not pass verification, or if the
TAK object does not include a successor public key, the RP
cancels the existing acceptance timer for this TA (if
applicable).
An RP MUST NOT use a successor public key for top-down validation
outside of the process described above, except for the purpose
of testing that the new public key is working correctly. This allows a
TA to publish a successor public key for a period of time, allowing RPs
to test it, while still being able to rely on RPs using the
current public key for their production RPKI operations.
A successor public key may have the same SubjectPublicKeyInfo value
as the current public key: this will be the case where a TA is updating
the certificateURIs for that public key.
Manual update of TA public key details
A Relying Party may opt not to support the automatic
transition of TA public key data, as defined in the previous section.
An alternative approach is for the Relying Party to alert the
user when a new successor public key is seen, and also when the
relevant acceptance timer has expired. The user can then
manually transition to the new TA public key data. This process
ensures that the benefits of the acceptance timer period are
still realised, as compared with TA public key update based on a TAL
distributed out-of-band by a TA.
Maintaining Multiple TA Key Pairs
Although an RP that can process TAK objects will only ever use one
public key for validation (either the current public key, or the
successor public key, once the relevant
acceptance timer has expired), an RP that cannot process TAK objects will continue to
use the public key details per its TAL (or equivalent manual configuration) indefinitely. As
a result, even when a TA is using a TAK object in order to migrate
clients to a new public key, the TA may
have to maintain the previous key pair for a period of time
alongside the new key pair
in order to ensure continuity of service for older clients.
For each TA key pair that a TA maintains, the signed material for
these key pairs MUST be published under different directories in the
context of the 'id-ad-caRepository' and 'id-ad-rpkiManifest'
Subject Information Access descriptions contained on the CA
certificates .
Publishing objects under the same directory is potentially
confusing for RPs, and could lead to object invalidity in the
event of file name collisions.
Also, the CA certificates for each maintained key pair, and the
content published for each key pair, MUST be equivalent (except for
the TAK object). In other words, for the purposes of RPKI
validation, it MUST NOT make a difference which of the public keys is
used as a starting point.
This means that the IP and Autonomous System (AS) resources contained on all
current CA certificates for the maintained
TA key pairs MUST be the same. Furthermore, for any delegation of IP and AS
resources to a child, the TA MUST have an equivalent CA certificate
published under each of its key pairs. Any updates in delegations
MUST be reflected under each of its key pairs. A TA SHOULD NOT publish any other objects besides a CRL,
a Manifest, a single TAK object, and any number of CA certificates for
delegation to child CAs.
If a TA uses a single remote publication server for its
key pairs, per
, then it MUST include all
<publish/> and <withdraw/> Protocol Data Units (PDUs) for the products of
each of its key pairs in a single query, in order to reduce the risk
of RPs seeing inconsistent data in the TA's RPKI repositories.
If a TA uses multiple publication servers, then the content for
different key pairs will be out of sync at times. The TA
SHOULD ensure that the
duration of these moments is limited to the shortest possible time.
Furthermore, the following
should be observed:
- In cases where a CA certificate is revoked, or replaced by a certificate with a
reduced set of resources, these changes will not take effect fully
until all the relevant repository publication points have been
updated. Given that TA private key operations are normally
performed infrequently, this is unlikely to be a problem: if the revocation or shrinking
of an issued CA certificate is staged for days/weeks, then experiencing a delay of
several minutes for the repository publication points to be updated is
relatively insignificant.
- In cases where a CA certificate is replaced by a certificate with
an extended set of resources, the
TA MUST inform the receiving CA only after all of its repository publication points have been
updated. This ensures that the receiving CA will not issue any products that could be invalid
if an RP uses a TA public key just before the CA certificate was due to be updated.
Finally, note that the publication locations of CA certificates for
delegations to child CAs under each key pair will be different, and
therefore the Authority Information Access 'id-ad-caIssuers' values
(section 4.8.7 of ) on certificates issued by
the child CAs may not be as expected when performing top-down
validation, depending on the TA public key that is used. However, these values
are not critical to top-down validation, so RPs performing such
validation MUST NOT reject a certificate simply because this value
is not as expected.
Performing TA Key Rolls
In this section we describe how present-day RPKI TAs that use only one key pair, and
that do not use TAK objects, can use a TAK object to perform a planned
key rollover.
Phase 1: Add a TAK for Key Pair 'A'
Before adding a successor public key, a TA may want to confirm
that it can maintain a TAK object for its current key pair only. We
will refer to this key pair as key pair 'A' throughout this section.
Phase 2: Add a Key Pair 'B'
The TA can now generate a new key pair, called 'B'. The
private key of this key pair MUST now be used to create a
new CA certificate for the associated public key, and to issue equivalent CA certificates for delegations
to child CAs, as described in
.
At this point, the TA can also construct a new TAL file
for
the public key of key pair 'B', and test locally that the validation
outcome for the new public key is equivalent
to that of the other current public key(s).
When the TA is certain that the content for both public
keys is equivalent, and
wants to initiate the migration from 'A' to 'B', it
issues a new TAK object under key pair 'A', with the public
key from that key pair as the
current public key for that object, the public key from key
pair 'B' as the successor public key, and
no predecessor public key. It also issues a TAK object under key
pair 'B', with the public key from that key pair as the
current public key for that object, the public key from key pair 'A'
as the predecessor public key, and no successor public key.
Once this has happened, RP clients will start seeing the
new public key and setting acceptance timers accordingly.
Phase 3: Update TAL to point to 'B'
At about the time that the TA expects clients to start
setting the public key from key pair 'B' as the current public
key, the TA must release a new TAL file for that public key. It SHOULD use a different set of URIs in the TAL compared to the TAK
file, so that the TA can learn the proportion of RPs that can
successfully validate and use the updated TAK objects.
To support RPs that do not take account of TAK objects, the TA
should continue operating key pair 'A' for a period of time after the
expected migration of clients to the public key from 'B'. The length of that period of time is a
local policy matter for that TA: it might operate the key pair until no
clients are attempting to validate using the associated public key, for example.
Phase 4: Remove Key Pair 'A'
The TA SHOULD now remove all content from the repository
used by key pair 'A', and destroy the private key for that key
pair. RPs attempting to
rely on a TAL for the public key from key pair 'A' from this point will not be able to
perform RPKI validation for the TA, and will have to update
their local state manually, by way of a new TAL file.
Using TAK objects to distribute TAL data
Relying Parties must be configured with RPKI Trust Anchor data in
order to function correctly. This Trust Anchor data is typically
distributed in the Trust Anchor Locator (TAL) format defined in
RFC 8630. A TAK object can also serve as a format for
distribution of this data, though, because the TAKey data stored
in the TAK object contains the same data that would appear in a
TAL for the associated Trust Anchor.
Relying Parties may support conversion of TAK objects into TAL
files. Relying Parties that support conversion MUST validate the
TAK object using the process from section 3.3. One exception to
the standard validation process in this context is that a Relying
Party MAY treat a TAK object as valid, even though it is
associated with a Trust Anchor that the Relying Party is not
currently configured to trust. If the Relying Party is relying on
this exception when converting a given TAK object, the Relying
Party MUST communicate that fact to the user.
When converting a TAK object, a Relying Party MUST default to
producing a TAL file based on the 'current' TAKey in the TAK
object, though it MAY optionally support producing TAL files based
on the 'predecessor' and 'successor' TAKeys.
When converting a TAK object, a Relying Party MUST include in
the TAL file any comments from the corresponding TAKey.
If TAK object validation fails, then the Relying Party MUST NOT
produce a TAL file based on the TAK object.
Users should be aware that TAK objects distributed out-of-band
have similar security properties to TAL files (i.e. there is no
authentication). In particular, TAK objects that are not signed by
TAs with which the Relying Party is currently configured should
only be used if the source that distributes them is one the user
trusts to distribute TAL files.
If a Relying Party is not transitioning to new Trust Anchor data
using the automatic process described in section 5 or the
partially-manual process described in section 5.1, then the user
will have to rely on an out-of-band mechanism for validating and
updating the Trust Anchor data for the Relying Party. Users in
this situation should take similar care when updating a trust
anchor using a TAK object file as when using a TAL file to update
TA data.
Deployment Considerations
Relying Party Support
Publishing TAK objects while RPs do not support this standard
will result in those RPs rejecting these objects. It is not
expected that this will result in the invalidation of any other
object under a Trust Anchor.
Some RPs may purposefully not support this mechanism: for
example, they may be implemented or configured such that they
are unable to update local current public key data. TA operators
should take this into consideration when planning key
rollover. However, these RPs would ideally still notify their
operators of planned key rollovers, so that the operator could
update the relevant configuration manually.
Alternate Transition Models
Alternate models of TAL update exist and are
complementary to this mechanism. For example, TAs can
liaise directly with RP software developers to include
updated and reissued TAL files in new code releases, and use
existing code update mechanisms in the RP community to
distribute the changes.
Additionally, these non-TA channels for distributing TAL
data may themselves rely on monitoring for TAK objects and
then updating the TAL data in their distributions or
packages accordingly. In this way, TAK objects may be
useful even for RPs that don't implement in-band support for
the protocol.
Non-TA channels for distributing TAL data should ensure,
so far as is possible, that their update mechanisms take
account of any changes that a user has made to their local
TA public key configuration. For example, if a new public key is
published for a TA, but the non-TA channel's mechanism is
able to detect that a user had removed the TA's previous
public key
from their local TA public key configuration such that the user no
longer relies on it, then the mechanism should not by
default add the new public key to the user's TA public key
configuration.
Operational Considerations
Acceptance Timers
Acceptance timers are used in TAK objects in order to permit RPs
to test that the new public key is working correctly. This in turn means
that the TA operator will be able to gain confidence in the correct
functioning of the new public key before RPs are relying on that in their
production RPKI operations. If a successor public key is not working
correctly, a TA may remove that public key from the current TAK
object.
A TA that removes a successor public key from a TAK object SHOULD NOT add
the same successor public key back into the TAK object for that TA. This
is because there may be an RP that has fetched the TAK object
while the successor public key was listed in it, and has started an
acceptance timer accordingly, but has not fetched the TAK object
during the period when the successor public key was not listed in it. If
the unchanged successor public key is added back into the TA, such an RP
will transition to using the new TA public key more quickly than other
RPs, which may, in turn, make debugging and similar more
complicated. A simple way of addressing this problem in a
situation where the TA operator doesn't want to reissue the
SubjectPublicKeyInfo content for the successor public key that was
withdrawn is to update the URL set for the successor public key, since
RPs must take that URL set into account for the purposes of
initiating and cancelling acceptance timers.
Security Considerations
Previous Keys
A TA needs to consider the length of time for which it will
maintain previously-current key pairs and their associated
repositories. An RP that is seeded with old TAL data will run
for 30 days using the previous public key before migrating to
the next public key, due to the acceptance timer requirements,
and this 30-day delay applies to each new key pair that has
been issued since the old TAL data was initially published.
It may be better in these instances for the TA to send error
responses when receiving requests for the old publication
URLs, so that the RP reports an error to its operator and the
operator seeds it with up-to-date TAL data immediately.
Once a TA has decided not to maintain a previously-current
key pair and its associated repository, the TA SHOULD destroy
the associated private key. The TA SHOULD also reuse the TA
CA certificate URLs from the previous TAL data for the next
TAL that it generates. These measures will help to mitigate
the risk of an adversary gaining access to the private key and its
associated publication points in order to send
invalid/incorrect data to RPs seeded with the TAL data for
the corresponding public key.
TA Compromise
TAK objects do not offer protection against compromise of
the current TA private key or the successor TA private key.
TA private key
compromise in general is out of scope for this document.
While it is possible for a malicious actor to use TAK
objects to cause RPs to transition from the current TA
public key to a successor TA public key, such action is
predicated on the malicious actor having compromised the
current TA private key in the first place, so TAK objects do not
alter the security considerations relevant to this
scenario.
Alternate Transition Models
describes
other ways in which a TA may transition from one key pair to
another. Transition by way of an in-band process reliant on
TAK objects is not mandatory for TAs or RPs, though the fact
that the TAK objects are verifiable by way of the
currently-trusted TA public key is a benefit compared with existing
out-of-band mechanisms for TA public key distribution.
There will be a period of time where both the current
public key
and the successor public key are available for use, and RPs that are
initialised at different points of the transition process, or
from different out-of-band sources, may be using either the
current public key or the successor public key. TAs are required to ensure
so far as is possible that for the purposes of RPKI
validation, it makes no difference which public key is used.
IANA Considerations
Content Type
IANA is asked to register an object identifier for one
content type in
the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)"
registry as follows:
- Description: id-ct-signedTAL
- OID: 1.2.840.113549.1.9.16.1.50
- Specification: [section 3.1]
Signed Object
IANA is asked to add the following to the "RPKI Signed Objects" registry:
IANA is also asked to add the following note to the "RPKI
Signed Objects" registry:
Objects of the types listed in this registry, as well as
RPKI resource certificates and CRLs, are expected to be
validated using the RPKI.
File Extension
IANA is asked to add an item for the Signed TAL file extension to the "RPKI Repository Name
Schemes" created by [RFC6481] as follows:
Module Identifier
IANA is asked to register an object identifier for one module identifier in
the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)"
registry as follows:
- Description: RPKISignedTrustAnchorList-2021
- OID: 1.2.840.113549.1.9.16.0.74
- Specification: [this document]
Registration of Media Type application/rpki-signed-tal
IANA is asked to register the media type "application/rpki-signed-tal" in the "Media Types" registry as follows:
- Type name:
-
application
- Subtype name:
-
rpki-signed-tal
- Required parameters:
-
N/A
- Optional parameters:
-
N/A
- Encoding considerations:
-
binary
- Security considerations:
-
Carries an RPKI Signed TAL. This media type contains no active content. See the Security Considerations section of RFC XXXX for further information.
- Interoperability considerations:
-
N/A
- Published specification:
-
RFC XXXX
- Applications that use this media type:
-
RPKI operators
- Fragment identifier considerations:
-
N/A
- Additional information:
-
- Content:
-
This media type is for a signed object, as defined in RFC 6488, which contains trust anchor key material as defined in RFC XXXX.
- Magic number(s):
-
N/A
- File extension(s):
-
.tak
- Macintosh file type code(s):
-
N/A
Person & email address to contact for further information:
iesg@ietf.org
- Intended usage:
-
COMMON
- Restrictions on usage:
-
N/A
- Author:
-
sidrops WG
- Change controller:
-
IESG
Implementation Status
NOTE: Please remove this section and the reference to RFC 7942 prior to publication as an RFC.
This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.
According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".
APNIC
- Responsible Organization: Asia-Pacific Network Information Centre
- Location: https://github.com/APNIC-net/rpki-signed-tal-demo
- Description: A proof-of-concept for relying party TAK usage.
- Level of Maturity: This is a proof-of-concept implementation.
- Coverage: This implementation includes all of the features
described in version 16 of this specification, except for writing TAL
files based on TAK data. The repository
includes a link to various test TALs that can be used for testing TAK
scenarios, too.
- Contact Information: Tom Harrison, tomh@apnic.net
rpki-client
- Responsible Organization: Job Snijders, the OpenBSD project
- Location: https://www.rpki-client.org
- Description: A relying party implementation which can validate TAKs.
- Level of Maturity: Mature. Trust Anchor operators are encouraged to
use rpki-client as part of smoke testing to help ensure high
levels of standards compliance when introducing changes, and use
rpki-client in a continuous monitoring fashion to help maintain
high levels of operational excellence.
- Coverage: This implementation includes all features except TAK acceptance
timers.
- Contact information: Job Snijders, job@fastly.com
rpki-rs
- Responsible Organization: Tim Bruijnzeels, tim@ripe.net
- Location: https://github.com/NLnetLabs/rpki-rs/tree/signed-tal
- Description: Library support for encoding and decoding TAK objects.
- Level of Maturity: This is a proof-of-concept implementation.
- Coverage: This implementation includes support for encoding and decoding TAK objects.
- Contact information: Tim Bruijnzeels, tim@ripe.net
Revision History
03 - Last draft under Tim's authorship.
04 - First draft with George's authorship. No substantive revisions.
05 - First draft with Tom's authorship. No substantive revisions.
06 - Rob Kisteleki's critique.
07 - Switch to two-key model.
08 - Keepalive.
09 - Acceptance timers, predecessor keys, no long-lived CRL/MFT.
10 - Using TAK objects for distribution of TAL data.
11 - Manual update guidance, additional security considerations, identifier updates.
12 - TAK object comments.
13 - Removal of compromise text, extra RP support text, key destruction text, media type registration, signed object registry note.
14 - Keepalive.
15 - Additional implementation notes and editorial updates.
16 - Updates from Secdir and IESG reviews.
Acknowledgments
The authors wish to thank Martin Hoffmann for a thorough review of the
document, Russ Housley for multiple reviews of the ASN.1 definitions and
for providing a new module for the TAK object, Job Snijders for the
extensive suggestions around TAK object structure/distribution and
rpki-client implementation work, and Ties de Kock for text/suggestions
around TAK/TAL distribution and general security considerations.
References
Normative References
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER)
ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002
Informative References
ASN.1 Module
This appendix includes the ASN.1 module for the TAK object.
RPKISignedTrustAnchorList-2021
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs9(9) smime(16) mod(0) 74 }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
CONTENT-TYPE
FROM CryptographicMessageSyntax-2009 -- in [RFC5911]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) modules(0) id-mod-cms-2004-02(41) }
SubjectPublicKeyInfo
FROM PKIX1Explicit-2009 -- in [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ;
ct-signedTAL CONTENT-TYPE ::=
{ TYPE TAK IDENTIFIED BY
id-ct-signedTAL }
id-ct-signedTAL OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 50 }
CertificateURI ::= IA5String
TAKey ::= SEQUENCE {
comments SEQUENCE SIZE (0..MAX) OF UTF8String,
certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI,
subjectPublicKeyInfo SubjectPublicKeyInfo
}
TAK ::= SEQUENCE {
version INTEGER DEFAULT 0,
current TAKey,
predecessor [0] TAKey OPTIONAL,
successor [1] TAKey OPTIONAL
}
END