| Network Working Group | T. Bruijnzeels |
| Internet-Draft | NLnet Labs |
| Intended status: Standards Track | C. Martinez |
| Expires: April 19, 2019 | LACNIC |
| R. Austein | |
| Dragon Research Labs | |
| October 16, 2018 |
RPKI Signed Object for Trust Anchor Keys
draft-ietf-sidrops-signed-tal-02
Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] 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 Trust Anchor Keys (TAK), that can be used by Trust Anchors to signal their set of current keys and the location(s) of the accompanying CA certiifcates to Relying Parties, as well as changes to this set in the form of revoked keys and new keys, in order to support both planned and unplanned key rolls without impacting RPKI validation.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 19, 2019.
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by Relying Parties in the RPKI to locate and validate Trust Anchor (TA) certificates used in RPKI validation. However, until now there has been no formal way of notifying Relying Parties (RP) of updates to a TAL. Such updates may be needed in particular in case a Trust Anchor needs to perform a planned, or unplanned, key roll.
This document defines a new RPKI signed object that can be used to document the current set of keys and the loctaion(s) of the accompanying CA certificates, as well as any changes to this set. This allows RPs to be notified automatically of such changes, and enables Trust Anchors to pre-stage a number of operational keys so that planned and unplanned key rolls can be performed without risking the invalidation of the RPKI tree under the TA. We call this object the Trust Anchor Keys (TAK) object.
When Relying Parties (RPs) are first bootstrapped, they use any current TAL to discover a key and location(s) of the TA certificate(s) for a TA. The RP can then retreive and validating the TA certificate, and subsequently validate the manifest [RFC6486] and CRL [section 5 of @!RFC6487]. However, before processing any other objects it will then first validate the TAK object, if present. All enumarated new keys (and locations) are then added to a new list of current TA keys for this TA. The RP will then recursively fetch and validate the TA certificates, manifest, CRL and TAK objects for each of these keys. As a part of this process the RP will also compile a list of revoked keys enumarated by any of the validly signed TAK objects. As the final step the RP will then filter out any revoked TA keys from its new set. This new set now replaces the previous set.
If the key used to start this process is still considered current, then validation continues. But if the key was revoked, then validation is restarted using one of the remaining keys in the set.
This process allows Trust Anchors to operate a set of N current keys, where any key can effectively revoke any or all of the other keys to perform either a planned, or an unplanned, key roll. This also allows Trust Anchors to produce long lived TAK objects as forward pointers to RPs, and retire its old key when doing a key roll.
While the generic process is quite involved, the amount of work needed to support an envisioned normal key roll is fairly limited. Under normal circumstances a TA will typically have two current keys, so that is can perform an emergency roll over in case one of the keys is lost. This means that the RP will need to validate two TAK objects. However, typically these files will agree that both keys are current and validation continues.
When a key roll is executed a TA will remove one old key, and introduce one new (back-up) key. The RP will remove the old key from its set, and it will not be queried again, and it will add the new key and its TA certifcate location(s).
Only in a situation where an RP is very outdated can it be expected that the RP will have to discover several chained TAK object. But, since it will remove the outdated TALs in this process, this presents a one time cost only.
Note that in theory a TA can revoke all of its keys and make itself obsolete. In practice however, a well operated TA will have measures in place to prevent this. Furthermore they can protect themselves against key loss to adversaries through the use of such as the use of a Hardware Security Module (HSM) to protect keys. Protecting against this mis-operation would incur complexity and guesswork on the RPs. Therefore it is believed that it is best to keep the process straightforward, and offer a solution for the more likely issues of loss of a key, e.g. because an HSM or card set is broken, and planned key rolls.
The TAK object makes use of the template for RPKI digitally signed objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS) [RFC5652] wrapper for the Signed TALs 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 [RFC6488]), this document defines:
This document requests an OID for TAK objects as follows:
signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD }
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 [RFC6488])
The content of a TAK object is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690], and is defined as follows:
TAK ::= SEQUENCE {
version INTEGER DEFAULT 0,
current ::= SEQUENCE SIZE (1..MAX) OF CurrentKey,
revoked ::= SEQUENCE OF SubjectPublicKeyInfo
}
CurrentKey ::= SEQUENCE {
certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI,
subjectPublicKeyInfo SubjectPublicKeyInfo
}
CertificateURI ::= IA5String
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The version number of the TAK object MUST be 0.
This field defines the set of current keys (CurrentKey) according to the signer of this Signed TALs object.
This field defines a current TA Key, equivalent to [I-D.ietf-sidrops-https-tal]. This structure contains a sequence of one or more URIs and a SubjectPublicKeyInfo.
This field is equivalent to the URI section in section 2.1 of [I-D.ietf-sidrops-https-tal]. It MUST contain at least one CertificateURI element. Each CertificateURI element contains the IA5String representation of either an rsync URI [RFC5781], or an HTTPS URI [RFC7230].
This field contains a SubjectPublicKeyInfo [section 4.1.2.7 or @!RFC5280] in DER format [X.690].
This field contains the list of keys, identified by SubjectPublicKeyInfo, that are no longer to be used according to the signer of this document.
To determine whether a TAK object is valid, the RP MUST perform the following steps in addition to those specified in [RFC6488]:
If the above procedure indicates that the manifest is invalid, then the TAK object MUST be discarded and treated as though no TAK object were present.
As described in Section 6 a TA will most likely choose to operate two keys at any one time in order to be prepared for an emergency key roll. When a TA operates multiple keys, each key MUST use its own CA repository publication point as described in [RFC6481]. The CRL and Manifest [RFC6486] for each of these keys will be unique to each key, but the TA MUST ensure that equivalent CA certificates and RPKI signed objects are issued under each key. Note that this is similar to how such certificates and RPKI signed objects are re-issued as part of a lower level CA key roll, described in section 4 of [RFC6489].
The Trust Anchors MUST generate a new key pair and generate a new TA Certificate. For the Subject Information Access (see section 4.8.8.1 of [RFC6487]) this MUST use URIs that will be used by the new key to publish objects. These URIs MUST be uniqe for use by this new key only. The Internet Number Resources on this new certificate MUST be equivalent to those found on the current certificate.
The new TA certificate MUST be published under one or more new Certificate URIs for use by this new key only.
As decribed above, the TA MUST issue and publish equivalent CA certificates and RPKI signed objects under this new key.
It is RECOMMENDED that the TA now generates a new TAL [I-D.ietf-sidrops-https-tal] and verifies that the new Trust Anchor certificate can be retrieved from all locations, and that it generates the same results when it is used for top-down validation instead of (any of) the current TA key(s).
Note that the TA MAY choose to make this TAL available to Relying Parties, in particular to those that do not support TAK objects, and for inclusion in the distribution of RP software in order to minimise the overhead in bootstrapping fresh installations.
If a TA uses a single remote publication server for its keys using the RPKI publication protocol [RFC8181], 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:
A TA MAY choose to use TAK objects to communicate its set of current, and revoked keys. If a TA chooses to use TAK objects, then it SHOULD generate and publish TAK objects under each of its current keys. An exception to this rule exists when a TA has lost permanent access to one of its keys or the accompanying repository publication point. In such cases however, the key in question MUST be revoked as described below in Section 6.
A non-normative guideline for naming this object is that the filename chosen for the Signed TAL 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 [RFC6481] for generation of filenames. The filename extension of ".tak" MUST be used to denote the object as a TAK. Note that this is in-line with filename extensions defined in section 7.2 of [RFC6481]
In order to generate the TAK Objects, the TA MUST perform the following actions:
For simplicitly let's start with a situation where a TA has only one key. The TA wants to start using TAK objects to perform key rolls in future, so it introduces a TAK object under its single key 'A'. The repository structure looks as follows (irrelevant details omitted):
+--------------------+ | A.MFT | +--------------------+ | A.CRL <hash> | | A.TAK <hash> | | C1-A.CER <hash> | | C2-A.CER <hash> | +--------------------+ +--------------------+ | A.CRL | +--------------------+ | revocations.. | +--------------------+ +--------------------+ | A.TAK | +--------------------+ | current: A | | revoked: none | +--------------------+ +--------------------+ | C1-A.CER | +--------------------+ | resources: C1 res | | subject: C1 name | | pub key: C1 key | | SIA: C1 SIAs | | AKI: A | +--------------------+ +--------------------+ | C2-A.CER | +--------------------+ | resources: C2 res | | subject: C2 name | | pub key: C2 key | | SIA: C2 SIAs | | AKI: A | +--------------------+
So, the TA publishes a CRL and MFT under its key A, listing a TAK object and in this case two certificates issued to children 'C1' and 'C2' signed using key A. The TAK object lists key 'A' as the only current key, and has no revoked keys.
Relying Parties who have a TAL for key 'A' configured will discover the TAK object. If the RP does not support this object, it will reject this object but continue to validate the remaining RPKI tree as usual. If the RP does support TAK objects it will conclude that key 'A' is the one and only current key, and will proceed to validate the remaining RPKI tree as usual.
Now the TA prestages a new key 'B' and produces equivalent CA certificates for children 'C1' and 'C2', i.e. the resources, subject name, public key and SIA etc are all equivalent, but these certificates are signed under key 'B'. (See Section 4 for a more thorough description of this). The TAK object for key 'B' recognises both keys 'A' and 'B' as current.
The repostory structure and TAK object for key B are then as follows:
+--------------------+ | B.MFT | +--------------------+ | B.CRL <hash> | | B.TAK <hash> | | C1-B.CER <hash> | | C2-B.CER <hash> | +--------------------+ +--------------------+ | B.CRL | +--------------------+ | revocations.. | +--------------------+ +--------------------+ | B.TAK | +--------------------+ | current: A, B | | revoked: none | +--------------------+ +--------------------+ | C1-B.CER | +--------------------+ | resources: C1 res | | subject: C1 name | | pub key: C1 key | | SIA: C1 SIAs | | AKI: B | +--------------------+ +--------------------+ | C2-B.CER | +--------------------+ | resources: C2 res | | subject: C2 name | | pub key: C2 key | | SIA: C2 SIAs | | AKI: B | +--------------------+
When the TA is certain that the content for key 'B' is correct, it can also update the TAK object for key 'A' to include 'B':
+--------------------+ | A.TAK | +--------------------+ | current: A, B | | revoked: none | +--------------------+
One way to do this is by generating a TAL [I-D.ietf-sidrops-https-tal] for key B and verifying that validation using this yields the same results as validation using the TAL for key A would. However, note, that it is preferred that this is done as part of an automated process that is sufficiently well tested, and that the contents of the repositories for keys 'A' and 'B' are updated as a single delta if the publication protocol [RFC8181] is used (see also: Section 5).
Relying Parties who have a TAL for key 'A' configured will discover the TAK object. If the RP does not support this object, it will reject this object but continue to validate the remaining RPKI tree as usual. If the RP does support TAK objects it will conclude that there are now two keys 'A' and 'B', and no revoked keys that it should be aware of. Since key 'A' is still current, the RP will continue to validate the RPKI tree structure using the repository for key 'A', ignoring the non-TAK objects in the repository for key 'B'.
The result will be the same for Relying Parties who have a TAL for key 'B' configured, because both keys are equivalent at this time.
The TA has now decided that key 'A' must be revoked. It still has access to this key and the repository, so it can perform a planned key roll. In addition to revoking key 'A', the TA will also generate new key 'C' to ensure that it has at least two current keys at all times for redundancy.
Keys 'B' and 'C' will become current keys on the TAK objects for all keys: 'A', 'B' and 'C'. Key 'A' will become part of the revoked keys on the TAK objects for keys 'A' and 'B'. Note that it is not needed to list key 'A' as revoked on the TAK file for key 'C', because RPs will only learn about key 'C' at the same time as learning about the revocation of key 'A' (see also below).
The TA will publish a long-lived TAK file and MFT and CRL only for key 'A' and publish these objects as waypointers for RPs that have a TAL pointing at key 'A' before destroying key 'A'.
The resulting structure for key 'A' will be as follows:
+--------------------+ | A.MFT | +--------------------+ | A.CRL <hash> | | A.TAK <hash> | +--------------------+ +--------------------+ | A.CRL | +--------------------+ | revocations.. | +--------------------+ +--------------------+ | A.TAK | +--------------------+ | current: B, C | | revoked: A | +--------------------+
The resulting structures for keys 'B' and 'C' will be as follows:
+--------------------+ +--------------------+ | B.MFT | | C.MFT | +--------------------+ +--------------------+ | B.CRL <hash> | | B.CRL <hash> | | B.TAK <hash> | | B.TAK <hash> | | C1-B.CER <hash> | | C1-C.CER <hash> | | C2-B.CER <hash> | | C2-C.CER <hash> | +--------------------+ +--------------------+ +--------------------+ +--------------------+ | B.CRL | | C.CRL | +--------------------+ +--------------------+ | revocations.. | | revocations.. | +--------------------+ +--------------------+ +--------------------+ +--------------------+ | B.TAK | | C.TAK | +--------------------+ +--------------------+ | current: B, C | | current: B, C | | revoked: A | | revoked: <none> | +--------------------+ +--------------------+ +--------------------+ +--------------------+ | C1-B.CER | | C1-C.CER | +--------------------+ +--------------------+ | resources: C1 res | | resources: C1 res | | subject: C1 name | | subject: C1 name | | pub key: C1 key | | pub key: C1 key | | SIA: C1 SIAs | | SIA: C1 SIAs | | AKI: B | | AKI: C | +--------------------+ +--------------------+ +--------------------+ +--------------------+ | C2-B.CER | | C2-B.CER | +--------------------+ +--------------------+ | resources: C2 res | | resources: C2 res | | subject: C2 name | | subject: C2 name | | pub key: C2 key | | pub key: C2 key | | SIA: C2 SIAs | | SIA: C2 SIAs | | AKI: B | | AKI: B | +--------------------+ +--------------------+
In addition to this the TA SHOULD reach out to RP vendors so that they can update the TAL included in the RP software distribution to use key 'B'.
Relying Parties who have a TAL for key 'A' configured will discover the TAK object. If the RP does not support this object, it will reject this object but continue to validate the remaining RPKI tree as usual. In this case that means that validation will stop, because there are no more objects under key 'A'. Therefore it is important that RPs that do not support TAK files are updated to use the TAL for key 'B' through some other process.
If the RP uses a TAL for key 'A' and it supports TAK objects, it will discover that the TAL for key 'A' has keys 'B' and 'C' as current, and revokes itself. It will then proceed to process keys 'B' and 'C' and find TALs which list the same current keys. So, it will now replace its notion of the current key set for this TA based on its TAL (key 'A') with what it learned. To keep things simple the RP will now conclude that it should re-start validation using a remaining current key, in this case key either 'B' or 'C' may be used.
If the RP already had a TAL for key 'B' and it supports TAK objects, or it simply started with key 'B' because it added it to its set of current keys when this key was pre-staged (see Section 6.2), it will learn that key 'A' is revoked and therefore will not attempt to verify the TAK file for key 'A'. It will also learn about key 'C' and inspect this key's TAL, and discover that only keys 'B' and 'C' are considered current. Since it started the validation process with a key that is still current, it can proceed to validate the RPKI tree using the repository under key 'B'.
Now keys 'B' and 'C' are current. The TA may have intended to revoke key 'B', essentially rolling over to key 'C' and a new key 'D', but let us suppose that the TA lost access to key 'C'. In this case the TA will simply revoke key 'C' instead, and still introduce a new key 'D'.
The major difference with the process described above for planned rolls, is that now the TA will not be able to update the TAK object, MFT or CRL for key 'C'. However, because all TAL objects for current keys are evaluated before tree validation is performed, it is safe to leave these objects in a repository. Keys 'B' and 'D' will simply mark key 'C' as being revoked.
If an RP still has a TAL pointing at key 'C' it will discover that key 'D' is added, and that key 'B' has been revoked through the TAK object published for keys 'B' and 'D'. At least, as long as the the MFT and TAK EE certificates have not expired, and the CRL and MFT are not stale.
If the TA is absolutely sure that the TAL for key 'C' never shipped with any RP distribution, then it would also be safe to delete the repository key 'C' altogether. RPs will learn that 'C' is revoked, and therefore will not even attempt to download the TAK object. However, it is hard to be certain of this and there this is NOT RECOMMENDED.
Including Signed TAL objects while RP tools do not support this standard will result in these RPs rejecting these objects. It is not expected that this will result in the invalidation of any other object under a Trust Anchor.
That said, the flagging mechanism introduced here can only be relied on once a majority of RPs support it. Defining when that moment arrives is by definition something that cannot be established at the time of writing this document. Until such time, TAs SHOULD continue to generate unsigned TAL files [I-D.ietf-sidrops-https-tal], and indicate which should be considered their current TAL, and communicate them to RPs through other means.
However, once a majority of RPs support this mechanism it would be RECOMMENDED that Trust Anchor operators perform key rolls regularly. The most assured way to know that such key rolls will work is by making them a part of normal operations. Determining when this moment arrives is by definition out of scope for this document, as it should be based on operational experience.
IANA is to add the following to the "RPKI Signed Objects" registry:
Decimal | Description | References --------+--------------------------------+--------------- TBD | Trust Anchor Keys | [section 3.1]
IANA is to add an item for the Signed TAL file extension to the "RPKI Repository Name Scheme" created by [RFC6481] as follows:
Extension | RPKI Object | References
-----------+-------------------------------------------
.tak | Trust Anchor Keys | [this document]
TBD
The authors wish to thank Martin Hoffmann for a thourough review of this document.
| [RFC5652] | Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, DOI 10.17487/RFC5652, September 2009. |