RPKI signed object for TALRIPE NCCtim@ripe.netLACNICcarlos@lacnic.net
Trust Anchor Locators (TALs) are used by Relying Parties
in the RPKI to locate and validate Trust Anchor certificates used in RPKI validation.
This document defines an RPKI signed object for a Trust
Anchor Locator (TAL) that can be published by Trust Anchor to communicate a new TAL
to already deployed Relying Parties. The two primary use cases for this are that
1) a Trust Anchor may wish to change the locations where its TA certificate may be
found, and 2) a Trust Anchor may wish to perform a planned migration to a new key.
Note that unplanned key rolls are considered out of scope for this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in .
Trust Anchor Locator (TAL) files are used in the Resource
Public Key Infrastructure (RPKI) to help Relying Parties locate and verify a trust
anchor certificate. A TAL file consists of:
One or more rsync URIs A subjectPublicKeyInfo in DER format
, encoded in Base64
The TAL can be distributed out-of-band to Relying Parties (RP), and it allows the
RP to retrieve the most recent version of the Trust Anchor (TA) certificate from
the cited location, and verify that public key of this certificate matches the TAL.
This is useful as it allows selected data in the trust anchor to change, without
needing to effect redistribution of the trust anchor per se. In particular the
Internet Number Resources (INRs) extension and the
publication points defined in the Subject Information Access
may be updated this way.
The assumption is that both the URIs and key of the TA certificate remain stable.
However, an organisation operating a TA may wish to change either of these
properties, because of a need to:
change one or more URIsperform a planned key roll
In this document we describe a method for TA operators to publish a an updated TAL
in a secure a well-defined fashion, so that RPs can be alerted about these changes.
Note that describes Automated Updates of DNS Security
(DNSSEC) Trust Anchors and can provide some useful insight here as well. However,
concepts like a set of Trust Anchors, standby Trust Anchors, and TTLs are not
applicable to the RPKI. Therefore we believe that an alternative approach based
on already existing concept of the Trust Anchor Locator
is appropriate.
A signed TAL is an RPKI signed object, as specified in .
The RPKI signed object template requires specification of the following data
elements in the context of the manifest structure.
This document requests an OID for signed-Tal 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 content of a Signed TAL is ASN.1 encoded using the Distinguished Encoding
Rules (DER) , and is defined as follows:The "SignedTalContent" contains the content of the new TAL encoded in Base64
.Before a Relying Party can use a Signed TAL, the relying party MUST first
validate the Signed TAL. To validate a Signed TAL, the relying party MUST perform
all the validation checks specified in as well as the
following additional specific validation step.The eContentType in the EncapsulatedContentInfo has OID
1.2.840.113549.1.9.16.1.TBD.The EE certificate of this Signed TAL is signed by a known Trust AnchorThe decoded TAL content conforms to the format defined in
If the above procedure indicates that the manifest is invalid, then the Signed
TAL MUST be discarded and treated as though no Signed TAL were present.
A TA MAY choose to generate a single Singed TAL object to publish in its TA
certificate publication point(s) in the RPKI. The TA MUST perform the following
steps to generate the Signed TAL:
Generate a key pair for a "one-time-use" EE certificate to use for the Signed
TALGenerate a one-time-use EE certificate for the Signed TALThis 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 Sigend TAL 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 is before the moment
that the Signed TAL will be published.This EE certificate MUST have a "notAfter" time that reflects the intended
time that this Signed TAL will be published. If the EE certificate for a
Signed TAL is expired, it MUST no longer be publish, but of course it MAY
be replaced by a newly generated Signed TAL object with similar content and
an updated "notAfter" time.
A TA MAY publish a single Signed TAL object directly under its CA repository
publication points. A non-normative guideline for naming this object is that the
filename chosen for the signed TAL 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 ".tal" MUST be used to denote the object
as a signed TAL. Note that this is in-line with filename extensions defined in
section 7.2 of .
A Signed TAL MAY be used to communicate a planned key roll for the TA.
Prior to publishing the Signed TAL for the new key the TA MUST perform the
following steps:Generate a new key pair for the new TA certificateGenerate a new TA Certificate, using a Subject Information Access for CA
certificates (see section 4.8.8.1 of ) that
references the URIs that will be used by the new key to publish objects,
that are different from the URIs used by the TA certificate for the
current key.ALL current signed certificates and other objects, with the exception of
the old CRL, Manifest and Signed TAL, must be re-issued by the new key
and published under the new publication point(s).The new TA certificate itself MUST be published in a (number of)
new location(s) that are different from where the TA certificate for the
current key is published.After these steps are performed a new Signed TAL MUST be generated as
described in , and published as described in
.
The staging period is initiated by the initial publication of a Signed TAL for
the new key and must be last at least 24 HOURS. During the staging period the
TA MUST continue to operate both the old and the new TA key. Note that this is
the same staging period used for key roll of normal CAs in the RPKI, described
in .The TA SHOULD preserve a Signed TAL for the old key after the staging period
as a hint for RPs that missed the key roll. The following process can be used
to achieve this:Produce a new long-lived CRL that revokes all previously signed
certificatesProduce a new long-lived Signed TALProduce a new long-lived manifest that includes the CRL and Signed TALPublish the CRL, MFT and Signed TALDestroy the old TA keyThe TA SHOULD retire and delete its old key after the staging period is over.When an RP discovers a valid Signed TAL signed under a TA, and it notices
that the contained TAL is different from its current TAL for this TA and
that the "subjectPublicKeyInfo" has changed, then the RP MUST replace the
TAL for this TA with the new TAL, abort the current top-down validation
operation, and initiate a new top-down validation operation using the
updated TAL.It is RECOMMENDED that the software informs the operator of this event.A signed TAL MAY be used to communicate an addition or removal of one or more
publication locations where the TA certificate can be found.When adding a publication point for a TA certificate, the TA MUST publish the
certificate in the new location(s) prior to publication of the Signed TAL.When removing a publication point for TA certificate, the TA SHOULD observe a
staging period of at least 24 Hours. The staging period is initiated by the
publication of an updated Signed TAL where the publication point has been
removed. During the staging period the TA SHOULD keep the old publication
point up to date and available.It is RECOMMENDED that a Trust Anchor publishes a valid Signed TAL for what
it believes its current TAL should be at all times.
When an RP discovers a valid Signed TAL signed under a TA, and it notices
that the contained TAL is different from its current TAL for this TA and
that the "subjectPublicKeyInfo" has not changed, then the RP MUST replace
the TAL for this TA with the new TAL for future use, but can continue the
current top-down validation operation.It is RECOMMENDED that the software informs the operator of this event.IANA is to add the following to the "RPKI Signed Objects" registry:IANA is to add an item for the Signed TAL file extension to the "RPKI Repository
Name Scheme" created by as follows:TBDTBD
Recommendation X.509: The Directory - Authentication Framework
ITU-T Recommendation X.509 (2000)
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