RPKI Signed Object for Trust Anchor Key
LACNIC
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
NLnet Labs
tim@nlnetlabs.nl
https://www.nlnetlabs.nl/
Dragon Research Labs
sra@hactrn.net
Internet
A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in
the Resource Public Key Infrastructure (RPKI) to locate and
validate a Trust Anchor (TA) Certification Authority (CA)
certificate used in RPKI validation. This document defines an
RPKI signed object for a Trust Anchor Key (TAK), that can be used
by a TA to signal the location(s) of the accompanying CA
certificate for the current key to RPs, as well as the successor
key and the location(s) of its CA certificate. This object helps
to support planned key rolls without impacting RPKI validation.
Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14
when,
and only when, they appear in all capitals, as shown here.
Overview
A TAL is used by an RP in the RPKI to
locate and validate TA CA certificates used in RPKI validation.
However, until now there has been no in-band way of notifying RPs of
updates to a TAL. In-band notification means that TAs can be
more confident of RPs being aware of key roll operations.
This document defines a new RPKI signed object that can be used to
document the location(s) of the TA CA certificate for the current TA
key, as well as the value of the successor key and the location(s) of
its TA CA certificate. This allows RPs to be notified automatically of
such changes, and enables TAs to stage a successor key so that
planned key rolls can be performed without risking the
invalidation of the RPKI tree under the TA. We call this object the
Trust Anchor Key (TAK) object.
When RPs are first bootstrapped, they use a TAL to discover
the key and location(s) of the CA certificate for a TA. The RP
can then retrieve and validate the CA certificate, and
subsequently validate the manifest and CRL published by that TA (section 5 of
). However, before
processing any other objects it will first validate the TAK
object, if present. If the TAK object lists only the current
key, then the RP continues processing as per normal. If the TAK
object includes a successor key, the RP starts an acceptance
timer, and then continues processing as per normal. If, during
the following validation runs up until the expiry of the
acceptance timer, the RP has not observed any changes to the
keys and certificate URLs listed in the TAK object, then the RP
will fetch the successor key, update its local state with that
key and its associated certification location(s), and continue
processing using that key.
The primary motivation for this work is being able to migrate
from a Hardware Security Module (HSM) produced by one vendor to
one produced by another, where the first vendor does not support
exporting keys for use by the second. There may be other
scenarios in which key rollover is useful, though.
TAK Object Definition
The TAK object makes use of the template for RPKI digitally signed objects
,
which defines a Cryptographic Message Syntax (CMS)
wrapper for the content as well as a generic validation procedure for RPKI signed objects. Therefore, to
complete the specification of the TAK object (see Section 4 of
), this document
defines:
- 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 requests an OID for the TAK object as follows:
This OID MUST appear both within the eContentType in the
encapContentInfo object, as well as
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 key, similarly to . It contains a sequence of one or more URIs and a
SubjectPublicKeyInfo.
certificateURIs
This field is 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 key of the repository in
which the TAK object is published.
predecessor
This field contains the TA key that was in use
for this TA immediately prior to the current TA key, if
applicable.
successor
This field contains the TA key to be used in place of
the current key, 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 EE certificate of the TAK object).
- The TA CA has published only one TAK object in its repository for this 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 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 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
migration of users to new certificateURIs should
happen by way of the successor key process.
TAK Object Generation and Publication
A TA MAY choose to use TAK objects to communicate its
current, predecessor, and
successor keys. If a
TA chooses to use TAK objects, then it SHOULD generate and publish TAK objects under
each of its keys.
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 key pair for a "one-time-use" EE
certificate to use for the TAK.
- The TA MUST generate a one-time-use EE certificate for the TAK.
- This EE certificate MUST have an 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
, an
extension is required in the EE certificate used
for this object. 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 explicit description of 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 key for the TAK MUST match that of the TA CA
certificate under which the TAK was issued.
Relying Party Use
Relying Parties MUST keep a record of the current key for each
configured TA, as well as the URI(s) where the CA certificate for this
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 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 key, then the RP must
verify the successor key by doing the following:
- performing top-down validation using the
successor 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 key matches the
initial TAK object's successor key; and
- ensuring that the successor TAK object's predecessor key matches
the initial TAK object's current key.
If any of these steps fails, then the successor key has failed
verification.
If the successor key passes verification, and the RP has not
seen that successor key on the previous successful validation
run for this TA, then the RP:
- sets an acceptance timer of 30 days for this
successor 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 key.
If the successor key passes verification, and the RP has seen
that successor 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 key;
- otherwise, the RP updates its current known
key details for this TA to be those of the successor key, and then begins
top-down validation again using the successor key.
If the successor key does not pass verification, or if the
TAK object does not include a successor key, the RP
cancels the existing acceptance timer for this TA (if
applicable).
An RP MUST NOT use a successor key for top-down validation
outside of the process described above, except for the purpose
of testing that the new key is working correctly. This allows a
TA to publish a successor key for a period of time, allowing RPs
to test it, while still being able to rely on RPs using the
current key for their production RPKI operations.
A successor key may have the same SubjectPublicKeyInfo value
as the current key: this will be the case where a TA is updating
the certificateURIs for that key.
Maintaining Multiple TA Keys
Although an RP that can process TAK objects will only ever use one
key for validation (either the current key, or the successor key, once the relevant
acceptance timer has expired), an RP that cannot process TAK objects will continue to
use the 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 key, the TA may
have to maintain the previous key for a period of time alongside the new key
in order to ensure continuity of service for older clients.
For each TA key that a TA is maintaining,
the signed material for these keys 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, and the
contents published by each key, 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 keys is
used as a starting point.
This means that the IP and AS resources contained on all
current CA certificates for the maintained
TA keys 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 keys. Any updates in delegations
MUST be reflected under each of its keys. 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 keys, per
, then it MUST include all <publish/> and <withdraw/> PDUs for the products of
each of its keys in a single query, in order to ensure that they will reflect the same content at
all times.
If a TA uses multiple publication servers, then it is by definition inevitable that the content of
different keys will be out of sync at times. In such cases, the TA
SHOULD ensure that the
duration of these moments are limited to the shortest possible time.
Furthermore, the following
should be observed:
- In cases where a CA certificate is revoked completely, 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 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 fairly 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 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 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 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 will 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 roll.
Phase 1: Add a TAK for Key 'A'
Before adding a successor key, a TA may want to confirm
that it can maintain a TAK object for its current key only. We
will refer to this key as key 'A' throughout this section.
Phase 2: Add a Key 'B'
The TA can now generate a new key pair for key 'B'. This key MUST now be used to create a
new CA certificate for this 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
key 'B', and test locally that the validation outcome for the new key is equivalent
to that of the other current key(s).
When the TA is certain that both keys are equivalent, and
wants to initiate the migration from 'A' to 'B', it
issues a new TAK object under key 'A', with key 'A' as the
current key for that object, key 'B' as the successor key, and
no predecessor key. It also issues a TAK object under key
'B', with key 'B' as the current key for that object, key 'A'
as the predecessor key, and no successor key.
Once this has happened, RP clients will start seeing the
new 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 key 'B' as the current key, the TA must release a new TAL file for key
'B'. 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 'A' for a period of time after the
expected migration of clients to 'B'. The length of that period of time is a
local policy matter for that TA: it might operate the key until no
clients are attempting to validate using it, for example.
Phase 4: Remove Key 'A'
The TA SHOULD now remove all content from the repository
used by key 'A', and destroy the private key for key 'A'. RPs attempting to
rely on a TAL for key '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.
If TAK object validation fails, then the Relying Party MUST NOT
produce a TAL file based on the TAK object.
Deployment Considerations
Including 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.
The mechanism introduced here can only be relied on once a majority of
RPs support it. Defining when that moment arrives is something that cannot be
established at the time of writing this document. The use of unique
URIs for keys in TAK objects, different from those used for the corresponding
TAL files, should help TAs understand the proportion
of RPs that support this mechanism.
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 key data. TAs 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.
Security Considerations
A TA needs to consider the length of time for which it will
maintain previously-current keys and their associated
repositories. An RP that is seeded with old TAL data will run
for 30 days using the previous key before migrating to the next
key, due to the acceptance timer requirements, and this 30-day
delay applies to each new key that has been issued since the old
TAL data was initially published. It may be better in these
instances to have the old publication URLs simply fail to
resolve, 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 and its associated repository, it needs to consider how to
protect against an adversary gaining access to that key and its
associated publication points in order to send invalid/incorrect
data to RPs seeded with the TAL data for that key. One possible
mitigation here is to reuse the TA CA certificate URLs from that
TAL data for newer keys.
The use of acceptance timers means that an adversary that
gains access to a TA's current key is not able to migrate RPs to
a new key without delay. Although access to that key does
permit arbitrary action within the corresponding TA (assuming
that the adversary has control over the relevant publication
points), being unable to migrate RPs to a new key means that it
is possible for the TA operator to regain control over the key
and the TA itself, such that it may not be necessary for all RPs
to carry out manual reconfiguration.
If an adversary gains access to the key listed as the
successor to a TA's current key (i.e. listed as the successor,
but the acceptance timer period has not yet elapsed since it was
listed), the TA operator can recover from this by simply
removing the successor key from the TAK object.
In general, the risk of key compromise can be mitigated by
the use of Hardware Security Modules (HSMs) by TAs, which will
guard against theft of a private key, as well as operational
processes to guard against (accidental) misuse of the keys in an
HSM by operators.
Alternate models of TAL update exist and can be complementary
to this mechanism. For example, TAs can liaise directly with
validation 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.
IANA Considerations
OID
IANA is asked to add the following to the "RPKI Signed Objects" registry:
File Extension
IANA is asked to add an item for the Signed TAL file extension to the "RPKI Repository Name
Scheme" 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.TBD
- Specification: [this document]
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 08 of this specification. 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
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.
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, and Job Snijders
for the suggestion about using TAK objects for distribution of TAL
data.
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) TBD }
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) TBD }
CertificateURI ::= IA5String
TAKey ::= SEQUENCE {
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