draft-ietf-sidrops-signed-tal-00.txt   draft-ietf-sidrops-signed-tal-01.txt 
Network Working Group T. Bruijnzeels Network Working Group T. Bruijnzeels
Internet-Draft RIPE NCC Internet-Draft NLnet Labs
Intended status: Standards Track C. Martinez Intended status: Best Current Practice C. Martinez
Expires: May 17, 2018 LACNIC Expires: December 10, 2018 LACNIC
November 13, 2017 June 8, 2018
RPKI signed object for TAL RPKI signed object for TAL
draft-ietf-sidrops-signed-tal-00 draft-ietf-sidrops-signed-tal-01
Abstract Abstract
Trust Anchor Locators (TALs) [RFC7730] are used by Relying Parties in Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
the RPKI to locate and validate Trust Anchor certificates used in Relying Parties in the RPKI to locate and validate Trust Anchor
RPKI validation. This document defines an RPKI signed object certificates used in RPKI validation. This document defines an RPKI
[RFC6488] for a Trust Anchor Locator (TAL) that can be published by signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be
Trust Anchor to communicate a new TAL to already deployed Relying used by Trust Anchors to perform a planned migration to a new key,
Parties. The two primary use cases for this are that 1) a Trust allowing Relying Parties to discover the new key up to one year after
Anchor may wish to change the locations where its TA certificate may the migration occurred.
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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2018. This Internet-Draft will expire on December 10, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Signed TAL definition . . . . . . . . . . . . . . . . . . . . 3 3. Signed TAL definition . . . . . . . . . . . . . . . . . . . . 3
3.1. The Signed TAL Content Type . . . . . . . . . . . . . . . 4 3.1. The Signed TAL Content Type . . . . . . . . . . . . . . . 4
3.2. The Signed TAL eContent . . . . . . . . . . . . . . . . . 4 3.2. The Signed TAL eContent . . . . . . . . . . . . . . . . . 4
3.3. Signed TAL Validation . . . . . . . . . . . . . . . . . . 4 3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 4
4. Signed TAL Generation . . . . . . . . . . . . . . . . . . . . 4 3.2.2. activationTime . . . . . . . . . . . . . . . . . . . 4
5. Signed TAL Publication . . . . . . . . . . . . . . . . . . . 5 3.2.3. certificateURIs . . . . . . . . . . . . . . . . . . . 4
6. Supporting a TA Key Roll . . . . . . . . . . . . . . . . . . 5 3.2.4. subjectPublicKeyInfo . . . . . . . . . . . . . . . . 4
6.1. Preparing a new TA key . . . . . . . . . . . . . . . . . 6 3.3. Signed TAL Validation . . . . . . . . . . . . . . . . . . 5
6.2. Staging period - Using both the old and the new TA key . 6 4. Signed TAL Generation . . . . . . . . . . . . . . . . . . . . 5
6.3. Preserving the Signed TAL . . . . . . . . . . . . . . . . 6 5. Signed TAL Publication . . . . . . . . . . . . . . . . . . . 6
6.4. Retiring the old key . . . . . . . . . . . . . . . . . . 7 6. Performing a planned Key Roll as a Trust Anchor . . . . . . . 6
6.5. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 6.1. Prepare a new Trust Anchor key and CA certificate . . . . 7
7. Supporting changing TA certificate publication point(s) . . . 7 6.2. Publish the new CA certificate . . . . . . . . . . . . . 7
7.1. Adding a publication point . . . . . . . . . . . . . . . 7 6.3. Verify the validity of the new CA certificate . . . . . . 7
7.2. Withdrawing a publication point . . . . . . . . . . . . . 7 6.4. Publish the objects under the current key under the new
7.3. Publishing the Signed TAL . . . . . . . . . . . . . . . . 7 key . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.4. Relying Party Use . . . . . . . . . . . . . . . . . . . . 7 6.5. Verify that the validity of objects under the new key . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.6. Publish a Signed TAL as the only object under the current
8.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 key . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. File Extension . . . . . . . . . . . . . . . . . . . . . 8 6.7. Delete the current key . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Unplanned Key Roll operations . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 10. Changing a Trust Anchor Certificate URIs . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 9 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.2. File Extension . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
14.1. Normative References . . . . . . . . . . . . . . . . . . 10
14.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Requirements notation 1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "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.
2. Introduction 2. Introduction
Trust Anchor Locator (TAL) files [RFC7730] are used in the Resource Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
Public Key Infrastructure (RPKI) to help Relying Parties locate and Relying Parties in the RPKI to locate and validate Trust Anchor
verify a trust anchor certificate. A TAL file consists of: certificates used in RPKI validation. This document defines an RPKI
signed object [RFC6488] for a Trust Anchor Locator (TAL) that can be
o One or more rsync URIs [RFC5781] used by Trust Anchors to perform a planned migration to a new key,
allowing Relying Parties to discover the new key up to one year after
o A subjectPublicKeyInfo [RFC5280] in DER format [X.509], encoded in the migration occurred. (Note "one year" is arbitrary, and may be
Base64 changed in a future version of this document)
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 [RFC3779] and the
publication points defined in the Subject Information Access
[RFC6487] 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:
o change one or more URIs
o perform 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 [RFC5011] describes Automated Updates of DNS Security Note that [RFC5011] describes Automated Updates of DNS Security
(DNSSEC) Trust Anchors and can provide some useful insight here as (DNSSEC) Trust Anchors and can provide some useful insight here as
well. However, concepts like a set of Trust Anchors, standby Trust well. However, concepts like a set of Trust Anchors, standby Trust
Anchors, and TTLs are not applicable to the RPKI. Therefore we Anchors, and TTLs are not applicable to the RPKI. Therefore, an
believe that an alternative approach based on already existing alternative approach based on already existing concept of the Trust
concept of the Trust Anchor Locator [RFC7730] is appropriate. Anchor Locator [I-D.ietf-sidrops-https-tal], and top-down validation
of an RPKI Trust Anchor certificate tree, where objects are retrieved
from the RPKI repositories, is appropriate.
3. Signed TAL definition 3. Signed TAL definition
A signed TAL is an RPKI signed object, as specified in [RFC6488]. The Signed TAL makes use of the template for RPKI digitally signed
The RPKI signed object template requires specification of the objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
following data elements in the context of the manifest structure. [RFC5652] wrapper for the Signed TAL content as well as a generic
validation procedure for RPKI signed objects. Therefore, to complete
the specification of the Signed TAL (see Section 4 of [RFC6488]),
this document defines:
o The OID defined in Section 3.1 that identifies the signed object
as being a Signed TAL. (This OID appears within the eContentType
in the encapContentInfo object as well as the content-type signed
attribute in the signerInfo object).
o The ASN.1 syntax for the Signed TAL eContent defined in
Section 3.2. (This is the payload that specifies the AS being
authorized to originate routes as well as the prefixes to which
the AS may originate routes.)
o Additional steps to the validation steps specified in [RFC6488]
required to validate Signed TALs, defined in Section 3.3.
3.1. The Signed TAL Content Type 3.1. The Signed TAL Content Type
This document requests an OID for signed-Tal as follows: This document requests an OID for signed-Tal as follows:
signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) signed-Tal OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD } rsadsi(113549) pkcs(1) pkcs9(9) 16 id-smime (1) TBD }
This OID MUST appear both within the eContentType in the This OID MUST appear both within the eContentType in the
encapContentInfo object as well as the content-type signed attribute encapContentInfo object as well as the content-type signed attribute
in the signerInfo object (see [RFC6488]). in the signerInfo object (see [RFC6488])
3.2. The Signed TAL eContent 3.2. The Signed TAL eContent
The content of a Signed TAL is ASN.1 encoded using the Distinguished The content of a Signed TAL is ASN.1 encoded using the Distinguished
Encoding Rules (DER) [X.690], and is defined as follows: Encoding Rules (DER) [X.690], and is defined as follows:
SignedTalContent ::= IA5String SignedTAL ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
activationTime GeneralizedTime,
certificateURIs SEQUENCE SIZE (1..MAX) OF CertificateURI,
subjectPublicKeyInfo SubjectPublicKeyInfo }
The "SignedTalContent" contains the content of the new TAL encoded in CertificateURI ::= IA5String
Base64 [RFC4648].
SubjectPublicKeyInfo ::= IA5String
3.2.1. version
The version number of the SignedTAL MUST be 0.
3.2.2. activationTime
This field contains the time when this TAL is intended to replace any
previously known TAL for this Trust Anchor.
3.2.3. certificateURIs
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].
3.2.4. subjectPublicKeyInfo
This field is equivalent to the subjectPublicKeyInfo section in
section 2.1 of [I-D.ietf-sidrops-https-tal].
3.3. Signed TAL Validation 3.3. Signed TAL Validation
Before a Relying Party can use a Signed TAL, the relying party MUST To determine whether a Signed TAL is valid, the RP MUST perform the
first validate the Signed TAL. To validate a Signed TAL, the relying following steps in addition to those specified in [RFC6488]:
party MUST perform all the validation checks specified in [RFC6488]
as well as the following additional specific validation step.
o The eContentType in the EncapsulatedContentInfo has OID o The eContentType OID matches the OID described in Section 3.1
1.2.840.113549.1.9.16.1.TBD.
o The EE certificate of this Signed TAL is signed by a known Trust o The Signed TAL appears as the product of a Trust Anchor CA
Anchor certificate.
o This Trust Anchor CA has published only one Signed TAL object in
its repository, and this object appears on the Manifest as the
only entry using the ".tal" extension (see [RFC6481]). In case
more than one Signed TAL object is found, all such objects MUST be
considered invalid.
o The EE certificate of this Signed TAL describes its Internet
Number Resources (INRs) using the "inherit" attribute
o The decoded TAL content conforms to the format defined in o The decoded TAL content conforms to the format defined in
[RFC7730] Section 3.2.
If the above procedure indicates that the manifest is invalid, then If the above procedure indicates that the manifest is invalid, then
the Signed TAL MUST be discarded and treated as though no Signed TAL the Signed TAL MUST be discarded and treated as though no Signed TAL
were present. were present.
4. Signed TAL Generation 4. Signed TAL Generation
A TA MAY choose to generate a single Singed TAL object to publish in 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 its TA certificate publication point(s) in the RPKI. The TA MUST
perform the following steps to generate the Signed TAL: perform the following steps to generate the Signed TAL:
skipping to change at page 5, line 32 skipping to change at page 6, line 15
o This EE certificate MUST have a "notBefore" time that is before o This EE certificate MUST have a "notBefore" time that is before
the moment that the Signed TAL will be published. the moment that the Signed TAL will be published.
o This EE certificate MUST have a "notAfter" time that reflects the o This EE certificate MUST have a "notAfter" time that reflects the
intended time that this Signed TAL will be published. If the EE intended time that this Signed TAL will be published. If the EE
certificate for a Signed TAL is expired, it MUST no longer be certificate for a Signed TAL is expired, it MUST no longer be
publish, but of course it MAY be replaced by a newly generated publish, but of course it MAY be replaced by a newly generated
Signed TAL object with similar content and an updated "notAfter" Signed TAL object with similar content and an updated "notAfter"
time. time.
o The Signed TAL MUST have an "activationTime" that reflects when
Relying Parties MUST use use this new TAL in place of any
previously known TAL for this Trust Anchor.
5. Signed TAL Publication 5. Signed TAL Publication
A TA MAY publish a single Signed TAL object directly under its CA A TA MAY publish a single Signed TAL object directly under its CA
repository publication points. A non-normative guideline for naming repository publication points. The TA MUST NOT publish multiple
this object is that the filename chosen for the signed TAL in the Signed TAL objects at any time. It is RECOMMENDED that a TA
publication repository be a value derived from the public key part of publishes a Signed TAL object for its current key and CA certificate
the entity's key pair, using the algorithm described for CRLs in publication URIs at all times.
section 2.2 of [RFC6481] 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 [RFC6481].
6. Supporting a TA Key Roll 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 [RFC6481] 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 [RFC6481]
A Signed TAL MAY be used to communicate a planned key roll for the 6. Performing a planned Key Roll as a Trust Anchor
TA.
6.1. Preparing a new TA key A Signed TAL SHOULD be used to communicate a planned key roll by a
Trust Anchor. From the Trust Anchor perspective a planned key roll
consists of the following steps:
Prior to publishing the Signed TAL for the new key the TA MUST o Prepare a new Trust Anchor key and CA certificate, see Section 6.1
perform the following steps:
o Generate a new key pair for the new TA certificate o Publish the new CA certificate, see Section 6.2
o Generate a new TA Certificate, using a Subject Information Access o Verify the validity of the new CA certificate, see Section 6.3
for CA certificates (see section 4.8.8.1 of [RFC6487]) 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.
o ALL current signed certificates and other objects, with the o Publish the objects under the current key under the new key, see
exception of the old CRL, Manifest and Signed TAL, must be re- Section 6.4
issued by the new key and published under the new publication
point(s).
o The new TA certificate itself MUST be published in a (number of) o Verify that the validity of objects under the new key, see
new location(s) that are different from where the TA certificate Section 6.5
for the current key is published.
After these steps are performed a new Signed TAL MUST be generated as o Publish a Signed TAL as the only object under the current key, see
described in Section 4, and published as described in Section 5. Section 6.6
6.2. Staging period - Using both the old and the new TA key o Delete the current key, see Section 6.7
The staging period is initiated by the initial publication of a 6.1. Prepare a new Trust Anchor key and CA certificate
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 [RFC6489].
6.3. Preserving the Signed TAL The Trust Anchors MUST 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 TA SHOULD preserve a Signed TAL for the old key after the staging 6.2. Publish the new CA certificate
period as a hint for RPs that missed the key roll. The following
process can be used to achieve this:
o Produce a new long-lived CRL that revokes all previously signed The new CA certificate MUST be published under one or more new
certificates Certificate URIs for use by this new key only.
o Produce a new long-lived Signed TAL 6.3. Verify the validity of the new CA certificate
o Produce a new long-lived manifest that includes the CRL and Signed The Trust Anchor MUST generate a new (unsigned) TAL file
TAL [I-D.ietf-sidrops-https-tal] and verify with RP software that the new
Trust Anchor certificate can be retrieved from all locations and that
it matches the subjectPublicKeyInfo
o Publish the CRL, MFT and Signed TAL 6.4. Publish the objects under the current key under the new key
o Destroy the old TA key
6.4. Retiring the old key ALL current signed certificates and other objects, with the exception
of the CRL, Manifest and existing Signed TAL, must be re-issued by
the new key and published under the new publication point(s).
The TA SHOULD retire and delete its old key after the staging period It is RECOMMENDED that a new Signed TAL object is generated and
is over. published, listing the Certificate URIs for this new key, the
subjectPublicKeyInfo of this new key, and using an "activationTime"
that is effective immediately. Note that Relying Parties will not
discover this new Signed TAL object until they have effectively
switched over from the current key.
6.5. Relying Party Use 6.5. Verify that the validity of objects under the new key
The Trust Anchor MUST verify that validation using the new TAL file
generated in Section 6.3 results in the set of valid objects as when
the current TAL file is used.
6.6. Publish a Signed TAL as the only object under the current key
The Trust Anchor MUST publish a new Signed TAL, CRL and Manifest as
the only objects under the current, to be deleted, key. The
"nextUpdate" values of the Manifest and CRL objects SHOULD use a date
that is set at least one year into the future. (arbitrary value, open
to suggestions). The "notValidAfter" date on the Manifest and Signed
TAL EE certificate SHOULD use this same date. The Trust Anchor MUST
ensure that this Signed TAL, CRL and Manifest remain available for
download for this full period. Note that this is done to give RPs
the opportunity to discover the new key up to one year after the key
roll occurred.
6.7. Delete the current key
As the final step the current key, which has been replaced now,
SHOULD be deleted. The new key can now be marked as the current key.
7. Relying Party Use
When an RP discovers a valid Signed TAL signed under a TA, and it 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 notices that the "subjectPublicKeyInfo" has changed and/or the set of
this TA and that the "subjectPublicKeyInfo" has changed, then the RP "Certificate URIs" has changed from the values it knew for this TA,
MUST replace the TAL for this TA with the new TAL, abort the current and the "activationTime" is in the past, then the RP MUST accept
top-down validation operation, and initiate a new top-down validation these new values for this TA, abort the current top-down validation
operation using the updated TAL. operation, and initiate a new top-down validation operation using the
updated information.
It is RECOMMENDED that the software informs the operator of this Note that the Trust Anchor MUST have verified that all objects are
event. available under the new key (Section 6.5) and that that the TA CA
certificate can be retrieved and validated for all new URIs
(Section 6.3).
7. Supporting changing TA certificate publication point(s) 8. Deployment Considerations
A signed TAL MAY be used to communicate an addition or removal of one Including Signed TAL objects while RP tools do not support this
or more publication locations where the TA certificate can be found. 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.
7.1. Adding a publication point That said, the flagging mechanism introduced here can only be trusted
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.
When adding a publication point for a TA certificate, the TA MUST However, once the majority of RPs support this mechanism it would be
publish the certificate in the new location(s) prior to publication RECOMMENDED that Trust Anchor operators perform key rolls regularly.
of the Signed TAL.
7.2. Withdrawing a publication point The most assured way to know that such planned rolls will work is by
making them a part of normal operations.
When removing a publication point for TA certificate, the TA SHOULD 9. Unplanned Key Roll operations
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.
7.3. Publishing the Signed TAL The mechanism described in this document is not applicable to
uplanned key rolls. Unplanned key rolls could theoretically be
supported by a mechanism where a new key is introduced before it's
used, with the power to revoke the current key. This would have to
be signalled from the new key, as the TA may have lost access to its
current key.
It is RECOMMENDED that a Trust Anchor publishes a valid Signed TAL However, this introduces a great amount of operational complexity as
for what it believes its current TAL should be at all times. well as a new vulnerability: an adversary would need access to only
one of these keys in order to compromise a TA.
7.4. Relying Party Use With that in mind we believe, for now, that unplanned key rolls
should not be covered here, and would need to be communicated to
Relying Parties in some other out-of-band fashion.
When an RP discovers a valid Signed TAL signed under a TA, and it 10. Changing a Trust Anchor Certificate URIs
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 Earlier versions of this document included a description of how
event. Signed TAL objects could be used to signal a change of Certificate
URIs only; i.e. where the key is not changed.
8. IANA Considerations However, Relying Parties that do not support the mechanism described
in this document would not be able to learn about the changes in
URIs. While for RPs that do support this mechanism a planned key
roll will be a normal part of RPKI validation.
8.1. OID Therefore we believe that a planned key roll should be used in cases
like this, and that the set of Certificate URIs for any given key
must never be changed.
IANA is to add the following to the "RPKI Signed Objects" registry: 11. IANA Considerations
Decimal Description References 11.1. OID
TBD signed-Tal [section 3.1] IANA is to add the following to the "RPKI Signed Objects" registry:
8.2. File Extension Decimal | Description | References
--------+--------------------------------+---------------
TBD | signed-Tal | [section 3.1]
11.2. File Extension
IANA is to add an item for the Signed TAL file extension to the "RPKI IANA is to add an item for the Signed TAL file extension to the "RPKI
Repository Name Scheme" created by [RFC6481] as follows: Repository Name Scheme" created by [RFC6481] as follows:
Extension RPKI Object Reference Extension | RPKI Object | References
------------------------------------------------------- -----------+-------------------------------------------
.tal Signed TAL [this document] .tal | Signed TAL | [this document]
9. Security Considerations 12. Security Considerations
TBD TBD
10. Acknowledgements 13. Acknowledgements
TBD TBD
11. References 14. References
11.1. Normative References 14.1. Normative References
[I-D.ietf-sidrops-https-tal]
Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", draft-ietf-sidrops-https-tal-03
(work in progress), June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
<https://www.rfc-editor.org/info/rfc4648>. September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI [RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010, Scheme", RFC 5781, DOI 10.17487/RFC5781, February 2010,
<https://www.rfc-editor.org/info/rfc5781>. <https://www.rfc-editor.org/info/rfc5781>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<https://www.rfc-editor.org/info/rfc6481>. <https://www.rfc-editor.org/info/rfc6481>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012, DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>. <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"Resource Public Key Infrastructure (RPKI) Trust Anchor Protocol (HTTP/1.1): Message Syntax and Routing",
Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7730>. <https://www.rfc-editor.org/info/rfc7230>.
[X.509] ITU-T Recommendation X.509 (2000), "Recommendation X.509: [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
The Directory - Authentication Framework", 2000. 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
"Information technology - ASN.1 encoding rules: "Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules Encoding Rules (CER) and Distinguished Encoding Rules
(DER)", 2002. (DER)", 2002.
11.2. Informative References 14.2. Informative References
[RFC5011] StJohns, M., "Automated Updates of DNS Security (DNSSEC)
Trust Anchors", STD 74, RFC 5011, DOI 10.17487/RFC5011,
September 2007, <https://www.rfc-editor.org/info/rfc5011>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
Authority (CA) Key Rollover in the Resource Public Key RFC 5652, DOI 10.17487/RFC5652, September 2009,
Infrastructure (RPKI)", BCP 174, RFC 6489, <https://www.rfc-editor.org/info/rfc5652>.
DOI 10.17487/RFC6489, February 2012,
<https://www.rfc-editor.org/info/rfc6489>.
Authors' Addresses Authors' Addresses
Tim Bruijnzeels Tim Bruijnzeels
RIPE NCC NLnet Labs
Email: tim@ripe.net
Email: tim@nlnetlabs.nl
URI: https://www.nlnetlabs.nl/
Carlos Martinez Carlos Martinez
LACNIC LACNIC
Email: carlos@lacnic.net Email: carlos@lacnic.net
URI: https://www.lacnic.net/
 End of changes. 72 change blocks. 
215 lines changed or deleted 292 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/