< draft-ietf-sidrops-signed-tal-02.txt   draft-ietf-sidrops-signed-tal-03.txt >
Network Working Group T. Bruijnzeels Network Working Group T. Bruijnzeels
Internet-Draft NLnet Labs Internet-Draft NLnet Labs
Intended status: Standards Track C. Martinez Intended status: Standards Track C. Martinez
Expires: April 19, 2019 LACNIC Expires: January 9, 2020 LACNIC
R. Austein R. Austein
Dragon Research Labs Dragon Research Labs
October 16, 2018 July 8, 2019
RPKI Signed Object for Trust Anchor Keys RPKI Signed Object for Trust Anchor Keys
draft-ietf-sidrops-signed-tal-02 draft-ietf-sidrops-signed-tal-03
Abstract Abstract
Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by
Relying Parties in the RPKI to locate and validate Trust Anchor Relying Parties in the RPKI to locate and validate Trust Anchor
certificates used in RPKI validation. This document defines an RPKI certificates used in RPKI validation. This document defines an RPKI
signed object for Trust Anchor Keys (TAK), that can be used by Trust 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 Anchors to signal their set of current keys and the location(s) of
the accompanying CA certiifcates to Relying Parties, as well as the accompanying CA certiifcates to Relying Parties, as well as
changes to this set in the form of revoked keys and new keys, in changes to this set in the form of revoked keys and new keys, in
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 19, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . 3 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. TAK Object definition . . . . . . . . . . . . . . . . . . . . 4 3. TAK Object definition . . . . . . . . . . . . . . . . . . . . 4
3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 5 3.1. The TAK Object Content Type . . . . . . . . . . . . . . . 4
3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 5 3.2. The TAK Object eContent . . . . . . . . . . . . . . . . . 4
3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. version . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. current . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. current . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.3. revoked . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.3. revoked . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 6 3.3. TAK Object Validation . . . . . . . . . . . . . . . . . . 6
4. Maintaining multiple TA keys . . . . . . . . . . . . . . . . 7 4. TAK Object Generation and Publication . . . . . . . . . . . . 6
4.1. Prepare a new TA key . . . . . . . . . . . . . . . . . . 7 5. Relying Party Use . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Publishing for Multiple TA Keys . . . . . . . . . . . . . 7 6. Maintaining multiple TA keys . . . . . . . . . . . . . . . . 8
5. TAK Object Generation and Publication . . . . . . . . . . . . 8 7. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 10
6. Performing TA Key Rolls . . . . . . . . . . . . . . . . . . . 9 7.1. Phase 1: Add a TAK for Key 'A' . . . . . . . . . . . . . 10
6.1. Opting in to Key Rolls . . . . . . . . . . . . . . . . . 10 7.2. Phase 2: Add a Key 'B' . . . . . . . . . . . . . . . . . 10
6.1.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 10 7.3. Phase 3: Roll to Key 'C' . . . . . . . . . . . . . . . . 11
6.1.2. Relying Parties . . . . . . . . . . . . . . . . . . . 12 7.3.1. Planned Direction Roll . . . . . . . . . . . . . . . 11
6.2. Pre-stage a New Key . . . . . . . . . . . . . . . . . . . 12 7.3.2. Unplanned Direction Roll . . . . . . . . . . . . . . 11
6.2.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 12 7.4. Phase X: Roll to Key 'D', 'E', .. . . . . . . . . . . . . 12
6.2.2. Relying Parties . . . . . . . . . . . . . . . . . . . 14 8. Deployment Considerations . . . . . . . . . . . . . . . . . . 12
6.3. Planned Key Revocation . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.3.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6.3.2. Relying Parties . . . . . . . . . . . . . . . . . . . 17 10.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.4. Unplanned revocation . . . . . . . . . . . . . . . . . . 17 10.2. File Extension . . . . . . . . . . . . . . . . . . . . . 13
6.4.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . 17 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 18 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. OID . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1. Normative References . . . . . . . . . . . . . . . . . . 13
8.2. File Extension . . . . . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Overview 2. Overview
Trust Anchor Locators (TALs) [I-D.ietf-sidrops-https-tal] are used by 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) Relying Parties in the RPKI to locate and validate Trust Anchor (TA)
certificates used in RPKI validation. However, until now there has certificates used in RPKI validation. However, until now there has
been no formal way of notifying Relying Parties (RP) of updates to a 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 TAL. Such updates may be needed in particular in case a Trust Anchor
needs to perform a planned, or unplanned, key roll. needs to perform a planned, or unplanned, key roll.
This document defines a new RPKI signed object that can be used to 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 document the current set of keys and the location(s) of the
accompanying CA certificates, as well as any changes to this set. accompanying CA certificates, as well as any changes to this set.
This allows RPs to be notified automatically of such changes, and This allows RPs to be notified automatically of such changes, and
enables Trust Anchors to pre-stage a number of operational keys so enables Trust Anchors to pre-stage a number of operational keys so
that planned and unplanned key rolls can be performed without risking 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 invalidation of the RPKI tree under the TA. We call this object
the Trust Anchor Keys (TAK) object. the Trust Anchor Keys (TAK) object.
When Relying Parties (RPs) are first bootstrapped, they use any When Relying Parties (RPs) are first bootstrapped, they use any
current TAL to discover a key and location(s) of the TA 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 certificate(s) for a TA. The RP can then retrieve and validating the
TA certificate, and subsequently validate the manifest [RFC6486] and TA certificate, and subsequently validate the manifest [RFC6486] and
CRL [section 5 of @!RFC6487]. However, before processing any other CRL [section 5 of @!RFC6487]. However, before processing any other
objects it will then first validate the TAK object, if present. All 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 enumerated 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 current TA keys for this TA. The RP will then recursively fetch and
validate the TA certificates, manifest, CRL and TAK objects for each 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 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 list of revoked keys enumerated by any of the validly signed TAK
objects. As the final step the RP will then filter out any revoked 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 TA keys from its new set. This new set now replaces the previous
set. 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, 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 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 perform either a planned, or an unplanned, key roll. This also
allows Trust Anchors to produce long lived TAK objects as forward allows Trust Anchors to produce long lived TAK objects as forward
pointers to RPs, and retire its old key when doing a key roll. 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
While the generic process is quite involved, the amount of work support an envisioned normal key roll is fairly limited. Under
needed to support an envisioned normal key roll is fairly limited. normal circumstances a TA will typically have two current keys, so
Under normal circumstances a TA will typically have two current keys, that is can perform an emergency roll over in case one of the keys is
so that is can perform an emergency roll over in case one of the keys lost. This means that the RP will need to validate one additional CA
is lost. This means that the RP will need to validate two TAK certificate, a CRL, a manifest and two TAK objects.
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 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 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 its set, and it will not be queried again, and it will add the new
key and its TA certifcate location(s). key and its TA certifcate location(s).
Only in a situation where an RP is very outdated can it be expected 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, that the RP will have to discover several chained TAK object. But,
since it will remove the outdated TALs in this process, this presents since it will remove the outdated TALs in this process, this presents
a one time cost only. 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.
3. TAK Object definition 3. TAK Object definition
The TAK object makes use of the template for RPKI digitally signed The TAK object makes use of the template for RPKI digitally signed
objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS) objects [RFC6488], which defines a Crytopgraphic Message Syntax (CMS)
[RFC5652] wrapper for the Signed TALs content as well as a generic [RFC5652] wrapper for the Signed TALs content as well as a generic
validation procedure for RPKI signed objects. Therefore, to complete validation procedure for RPKI signed objects. Therefore, to complete
the specification of the TAK object (see Section 4 of [RFC6488]), the specification of the TAK object (see Section 4 of [RFC6488]),
this document defines: this document defines:
o The OID defined in Section 3.1 that identifies the signed object o The OID defined in Section 3.1 that identifies the signed object
skipping to change at page 7, line 9 skipping to change at page 6, line 37
o The EE certificate of this TAK object describes its Internet o The EE certificate of this TAK object describes its Internet
Number Resources (INRs) using the "inherit" attribute Number Resources (INRs) using the "inherit" attribute
o The decoded TAK content conforms to the format defined in o The decoded TAK content conforms to the format defined in
Section 3.2. 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 TAK object MUST be discarded and treated as though no TAK object the TAK object MUST be discarded and treated as though no TAK object
were present. were present.
4. Maintaining multiple TA keys 4. TAK Object Generation and Publication
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].
4.1. Prepare a new TA key
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.
4.2. Publishing for Multiple TA Keys
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:
o It is strongly RECOMMENDED that TAs do not issue any RPKI Signed
Objects, such as ROAs [RFC6482], but limit their operations to
maintaining a CRL, Manifest and CA certificates only. If an
organisation maintaining a TA has an operational need for such
objects then it is strongly RECOMMENDED that they operate a
separate non-TA CA as a child of their TA for these operations.
If this approach is used the remaining issues regarding temporary
inconsistencies between multiple TA key repository publication
points is greatly reduced.
o In cases where a CA certificate is revoked completely, or replaced
by a certifcate with a reduced set of resources, these changes
will not take effect fully until all the TA keys repository
publication points have been updated. Given that TA key
operations are normally performed infrequently we don't expect
that this is a problem. I.e. if the revocation or shrinking of an
issued CA certificate is staged for days, or weeks anyway, then
experiencing a delay of several minutes for the repository
publication points to all be updated is fairly insignificant.
o In cases where a CA certificate is replaced by a certifcate with
an extend set of resources the TA MUST inform the receiving CA
only after all its repository publication points have been
updated. This ensures that the receiveing 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.
5. TAK Object Generation and Publication
A TA MAY choose to use TAK objects to communicate its set of current, 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 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 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 exception to this rule exists when a TA has lost permanent access to
one of its keys or the accompanying repository publication point. In one of its keys or the accompanying repository publication point. In
such cases however, the key in question MUST be revoked as described such cases however, the key in question MUST be revoked as described
below in Section 6. below in Section 7.
A non-normative guideline for naming this object is that the filename A non-normative guideline for naming this object is that the filename
chosen for the Signed TAL Object in the publication repository be a 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, 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] using the algorithm described for CRLs in section 2.2 of [RFC6481]
for generation of filenames. The filename extension of ".tak" MUST 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 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] with filename extensions defined in section 7.2 of [RFC6481]
In order to generate the TAK Objects, the TA MUST perform the In order to generate the TAK Objects, the TA MUST perform the
skipping to change at page 9, line 46 skipping to change at page 7, line 43
published, but it MAY be replaced by a newly generated TAK object published, but it MAY be replaced by a newly generated TAK object
with equivalent content and an updated "notAfter" time. with equivalent content and an updated "notAfter" time.
o The same set of current keys (see Section 3.2.2) MUST be included o The same set of current keys (see Section 3.2.2) MUST be included
on each TAK object for each current key. on each TAK object for each current key.
o The TAK object MUST include all revoked keys (see Section 3.2.3) o The TAK object MUST include all revoked keys (see Section 3.2.3)
that became revoked while the key signing the TAK in question was that became revoked while the key signing the TAK in question was
current. current.
6. Performing TA Key Rolls 5. Relying Party Use
6.1. Opting in to Key Rolls
6.1.1. Trust Anchor
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.
6.1.2. Relying Parties
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.
6.2. Pre-stage a New Key
6.2.1. Trust Anchor Relying Parties MUST keep a record of all current keys for each
configured Trust Anchor, as well as the URI(s) where the CA
certificate for each of these keys may be retrieved. This record MAY
be bootstrapped by the use of a pre-configured (and unsigned) TAL
file [I-D.ietf-sidrops-https-tal], but it MUST be updated with
authoritative signed information found in valid TAK objects found in
subsequent validation runs.
Now the TA prestages a new key 'B' and produces equivalent CA When performing top-down validation RPs MUST first validate and
certificates for children 'C1' and 'C2', i.e. the resources, subject process any TAK objects for each of its known current keys for a TA
name, public key and SIA etc are all equivalent, but these by performing the following steps:
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: o A CA certificate is retrieved and validated from the known URIs as
described in sections 3 and 4 of [I-D.ietf-sidrops-https-tal].
+--------------------+ o The manifest and CRL for this certificate are then validated first
| B.MFT | as described in [RFC6487] and [RFC6486].
+--------------------+
| B.CRL <hash> |
| B.TAK <hash> |
| C1-B.CER <hash> |
| C2-B.CER <hash> |
+--------------------+
+--------------------+ o The TAK file, if present, is validated as described in
| B.CRL | Section 3.3.
+--------------------+
| revocations.. |
+--------------------+
+--------------------+ For each valid TAK file thus found all current keys, i.e.
| B.TAK | SubjectPublicKeyInfo and URIs, are kept. If any previously unknown
+--------------------+ keys are added to the set of current keys, then they MUST also be
| current: A, B | processed as described above.
| revoked: none |
+--------------------+
+--------------------+ Once the TAK objects for all keys are processed the set of current
| C1-B.CER | keys and URIs for the TA is updated as follows: * All new current
+--------------------+ keys found on any valid TAK object are added to the set of current
| resources: C1 res | keys. * The set of URIs for each current key is replaced by the
| subject: C1 name | union of all URIs for this key found on all valid TAK objects. *
| pub key: C1 key | Finally, any current key that matches any revoked key on any valid
| SIA: C1 SIAs | TAK object is removed from the set of current keys.
| AKI: B |
+--------------------+
+--------------------+ Note that if a current key does not occur on any valid TAK object,
| C2-B.CER | but it is not revoked either, then it and any previously known URIs
+--------------------+ for it are kept. Also note that if an RP was bootstrapped using a
| resources: C2 res | TAL file [I-D.ietf-sidrops-https-tal], the keys and URIs will now
| subject: C2 name | have been replaced by values found on TAK objects.
| pub key: C2 key |
| SIA: C2 SIAs |
| AKI: B |
+--------------------+
When the TA is certain that the content for key 'B' is correct, it After this the RP can choose any one of the valid CA certificates for
can also update the TAK object for key 'A' to include 'B': any key that is still in the set of current keys for this TA, in
order to continue the top-down validation of object for this TA as
described in [RFC6487].
+--------------------+ 6. Maintaining multiple TA keys
| A.TAK |
+--------------------+
| current: A, B |
| revoked: none |
+--------------------+
One way to do this is by generating a TAL If a TA operates multiple keys, then the signed material for these
[I-D.ietf-sidrops-https-tal] for key B and verifying that validation keys MUST be published under different directories in the context of
using this yields the same results as validation using the TAL for the 'id-ad-caRepository' and 'id-ad-rpkiManifest' Subject Information
key A would. However, note, that it is preferred that this is done Access descriptions contained on the CA certificates [RFC6487].
as part of an automated process that is sufficiently well tested, and Publishing objects under the same space would lead to confusion at
that the contents of the repositories for keys 'A' and 'B' are best, and in case of file name collisions of objects invalidity.
updated as a single delta if the publication protocol [RFC8181] is
used (see also: Section 5).
6.2.2. Relying Parties However, the CA certificates for each key, and the contents published
by each key MUST be equivalent. In other words it MUST not make a
difference which of the keys is used as a starting point for top-down
validation by RP software.
Relying Parties who have a TAL for key 'A' configured will discover This means that the IP and AS resources contained on all current CA
the TAK object. If the RP does not support this object, it will certificates for the current TA keys MUST be the same. Furthermore
reject this object but continue to validate the remaining RPKI tree for any delegation of IP and AS resources to a child, the TA MUST
as usual. If the RP does support TAK objects it will conclude that have an equivalent CA certificate published under each of its keys.
there are now two keys 'A' and 'B', and no revoked keys that it Any updates in delegations MUST be reflected under each of its keys.
should be aware of. Since key 'A' is still current, the RP will A TA SHOULD NOT publish any other objects besides a CRL, a Manifest,
continue to validate the RPKI tree structure using the repository for a single TAK object, and any number of CA certificates for delegation
key 'A', ignoring the non-TAK objects in the repository for key 'B'. to child Certification Authorities.
The result will be the same for Relying Parties who have a TAL for If a TA uses a single remote publication server for its keys using
key 'B' configured, because both keys are equivalent at this time. 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.
6.3. Planned Key Revocation 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:
6.3.1. Trust Anchor o 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 TA keys repository
publication points have been updated. Given that TA key
operations are normally performed infrequently we don't expect
that this is a problem. I.e. if the revocation or shrinking of an
issued CA certificate is staged for days, or weeks anyway, then
experiencing a delay of several minutes for the repository
publication points to all be updated is fairly insignificant.
The TA has now decided that key 'A' must be revoked. It still has o In cases where a CA certificate is replaced by a certificate with
access to this key and the repository, so it can perform a planned an extend set of resources the TA MUST inform the receiving CA
key roll. In addition to revoking key 'A', the TA will also generate only after all its repository publication points have been
new key 'C' to ensure that it has at least two current keys at all updated. This ensures that the receiving CA will not issue any
times for redundancy. products that could be invalid if an RP uses a TA key just before
the CA certificate was due to be updated.
Keys 'B' and 'C' will become current keys on the TAK objects for all Finally, note that the publication locations of CA certificates for
keys: 'A', 'B' and 'C'. Key 'A' will become part of the revoked keys delegations to child CAs under each key will be different, and
on the TAK objects for keys 'A' and 'B'. Note that it is not needed therefore the Authority Information Access 'id-ad-caIssuers' value on
to list key 'A' as revoked on the TAK file for key 'C', because RPs certificates issued by the child CAs may not match (section 4.8.7 of
will only learn about key 'C' at the same time as learning about the [RFC6487]). However, this information is not considered critical for
revocation of key 'A' (see also below). validation of these objects and provided as hints to RP software
only. Therefore RP software MUST NOT reject these certificates based
on a mismatch of this value.
The TA will publish a long-lived TAK file and MFT and CRL only for 7. Performing TA Key Rolls
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: 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 change to
having two current keys at all times allowing them to perform both
planned and unplanned key rolls.
+--------------------+ 7.1. Phase 1: Add a TAK for Key 'A'
| A.MFT |
+--------------------+
| A.CRL <hash> |
| A.TAK <hash> |
+--------------------+
+--------------------+ Before adding any new keys a Trust Anchor may want to build up
| A.CRL | operational experience in maintaining a TAK object that describes its
+--------------------+ current key only. We will call refer to this key as key 'A'
| revocations.. | throughout this section.
+--------------------+
+--------------------+ The TA will have a TAL file [I-D.ietf-sidrops-https-tal] that
| A.TAK | contains one or more URIs where the (equivalent) CA certificates for
+--------------------+ this key 'A' can be retrieved. The TA can now generate a TAK objects
| current: B, C | that includes key 'A' only in its sequence of 'CurrentKey' values.
| revoked: A |
+--------------------+
The resulting structures for keys 'B' and 'C' will be as follows: The TA SHOULD publish the CA certificate for key 'A' at one or more
new locations not used in the TAL file, and use these new URIs in the
TAK object. The TA is free to choose any naming strategy for these
locations. As a non-normative suggestion, one such approach could be
to use the date that this phase was started as part of the file name
or a directory where the CA certificate is published.
+--------------------+ +--------------------+ The TA can now monitor the retrieval of its CA certificates from the
| B.MFT | | C.MFT | URI(s) in the newly published TAK object, relative to the retrieval
+--------------------+ +--------------------+ from the URI(s) listed in its TAL file, to learn the proportion of
| B.CRL <hash> | | B.CRL <hash> | RPs that can successfully validate and use the TAK object.
| B.TAK <hash> | | B.TAK <hash> |
| C1-B.CER <hash> | | C1-C.CER <hash> |
| C2-B.CER <hash> | | C2-C.CER <hash> |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ 7.2. Phase 2: Add a Key 'B'
| B.CRL | | C.CRL |
+--------------------+ +--------------------+
| revocations.. | | revocations.. |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ The TA can now generate a new key pair, key 'B'. This key MUST now
| B.TAK | | C.TAK | be used to create a new CA certificate for this key, and issue
+--------------------+ +--------------------+ equivalent CA certificates for delegations to child CAs, as described
| current: B, C | | current: B, C | in Section 6.
| revoked: A | | revoked: <none> |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ At this point, the TA can also issue a new TAL file
| C1-B.CER | | C1-C.CER | [I-D.ietf-sidrops-https-tal] for key 'B', and test locally that the
+--------------------+ +--------------------+ validation outcome for the new key is indeed equivalent to the other
| resources: C1 res | | resources: C1 res | current key(s).
| subject: C1 name | | subject: C1 name |
| pub key: C1 key | | pub key: C1 key |
| SIA: C1 SIAs | | SIA: C1 SIAs |
| AKI: B | | AKI: C |
+--------------------+ +--------------------+
+--------------------+ +--------------------+ When the TA is certain that both keys are equivalent, it MUST issue a
| C2-B.CER | | C2-B.CER | new TAK object under each of its current keys, and include both the
+--------------------+ +--------------------+ old key 'A' and this new key 'B' in the set of current keys.
| 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 The TA SHOULD now also release a new TAL file for this new key 'B' as
they can update the TAL included in the RP software distribution to the intended new key to be used by RP software. However, as
use key 'B'. described above, it SHOULD use a different set of URIs in the TAL
compared to the TAK file, so that it can learn the proportion of RPs
that can successfully validate and use the updated TAK objects.
6.3.2. Relying Parties 7.3. Phase 3: Roll to Key 'C'
Relying Parties who have a TAL for key 'A' configured will discover In this phase a new key, key 'C' is generated as described above in
the TAK object. If the RP does not support this object, it will Section 7.2. And one of the previous keys is revoked.
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 7.3.1. Planned Direction Roll
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, If the key roll is planned, and the TA has access to all its keys
or it simply started with key 'B' because it added it to its set of 'A', 'B' and 'C', and the publication servers for each of the keys,
current keys when this key was pre-staged (see Section 6.2), it will then a new TAK object is generated for each of these keys listing
learn that key 'A' is revoked and therefore will not attempt to keys 'B' and 'C' as current, and key 'A' as revoked.
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'.
6.4. Unplanned revocation The TA SHOULD now publish a long-lived TAK file, CRL and Manifest
under key 'A', remove all other content, and destroy key 'A'. This
way RP software that uses a TAL for key 'A' can still successfully
find keys 'B' and 'C', and in future 'D', 'E', etc.
6.4.1. Trust Anchor If access to key 'A' was lost, then the process is slightly
different. The TAK object for key 'A' cannot be updated and will
therefore still refer to keys 'A' and 'B' as the current keys, and
include no revocations. However, an updated TAK object listing keys
'B' and 'C' as current, and listing key 'A' as revoked can still be
issued and published under keys 'B' and 'C'. As described in
Section 5 RPs will then discover that key 'A' is revoked, and
continue to use keys 'B' and 'C'.
Now keys 'B' and 'C' are current. The TA may have intended to revoke 7.3.2. Unplanned Direction Roll
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 If key 'B' is compromised, the process is similar to above, except of
rolls, is that now the TA will not be able to update the TAK object, course that now keys 'A' and 'C' are included in the set of current
MFT or CRL for key 'C'. However, because all TAL objects for current keys, and key 'B' is in the set of revoked keys. If the TA still has
keys are evaluated before tree validation is performed, it is safe to access to key 'B', then it SHOULD publish a long-lived TAK file, CRL
leave these objects in a repository. Keys 'B' and 'D' will simply and manifest for key 'B' and remove all other content for it. If it
mark key 'C' as being revoked. cannot perform this action then simply marking key 'B' as revoked
will still notify RPs to disregard it.
If an RP still has a TAL pointing at key 'C' it will discover that 7.4. Phase X: Roll to Key 'D', 'E', ..
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 Further key rolls are essentially no different the roll to key 'C'
with any RP distribution, then it would also be safe to delete the described in Section 7.3, except that there is no need to still
repository key 'C' altogether. RPs will learn that 'C' is revoked, include key 'A' in the list of revoked keys when the the roll to key
and therefore will not even attempt to download the TAK object. 'D' is performed. RPs will already have learned to that key 'A' is
However, it is hard to be certain of this and there this is NOT revoked, before they learn about key 'D'.
RECOMMENDED.
7. Deployment Considerations 8. Deployment Considerations
Including Signed TAL objects while RP tools do not support this Including Signed TAL objects while RP tools do not support this
standard will result in these RPs rejecting these objects. It is not standard will result in these RPs rejecting these objects. It is not
expected that this will result in the invalidation of any other expected that this will result in the invalidation of any other
object under a Trust Anchor. object under a Trust Anchor.
That said, the flagging mechanism introduced here can only be relied That said, the flagging mechanism introduced here can only be relied
on once a majority of RPs support it. Defining when that moment on once a majority of RPs support it. Defining when that moment
arrives is by definition something that cannot be established at the arrives is by definition something that cannot be established at the
time of writing this document. Until such time, TAs SHOULD continue time of writing this document. The use of unique URIs in TAK objects
to generate unsigned TAL files [I-D.ietf-sidrops-https-tal], and compared to their equivalent TAL files should help operators
indicate which should be considered their current TAL, and understand which proportion of RPs support this mechanism.
communicate them to RPs through other means.
However, once a majority of RPs support this mechanism it would be 9. Security Considerations
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.
8. IANA Considerations It should be noted that because any key can revoke the other key(s),
a risk introduced: if an adversary can gain access to one of the
keys, and publication servers for it, then they can essentially take
over a TA. It should also be noted that a TA can revoke all of its
keys by accident and make itself obsolete.
8.1. OID However, these risks can be mitigated greatly by the use of Hardware
Security Modules (HSM) by TAs, which will guard against theft of a
private key, and operational processes to guard against (accidental)
mis-use of the keys in an HSM by operators.
Although HSMs can help against key theft, the risk of key loss is
still very applicable. In some ways more so, because back-ups are
hard by design. Key loss can easily happen for example when an
operator card set that is used to authorise use of a key in an HSM
can no longer be used, e.g. because cards are broken or lost, or a
persons who holds a card is sadly no longer with us, or passwords are
forgotten, etc.
In such cases the ability to perform an unplanned roll as described
in this document will be very useful, provided that access to the
both keys is arranged differently, and the issues affecting one key,
do not necessarily affect the other key.
An example where the planned rolls are useful is when a TA is using
an HSM from vendor X, and they want to migrate to an HSM from vendor
Y.
10. IANA Considerations
10.1. OID
IANA is to add the following to the "RPKI Signed Objects" registry: IANA is to add the following to the "RPKI Signed Objects" registry:
Decimal | Description | References Decimal | Description | References
--------+--------------------------------+--------------- --------+--------------------------------+---------------
TBD | Trust Anchor Keys | [section 3.1] TBD | Trust Anchor Keys | [section 3.1]
8.2. File Extension 10.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 | References Extension | RPKI Object | References
-----------+------------------------------------------- -----------+-------------------------------------------
.tak | Trust Anchor Keys | [this document] .tak | Trust Anchor Keys | [this document]
9. Security Considerations 11. Security Considerations
TBD TBD
10. Acknowledgements 12. Acknowledgements
The authors wish to thank Martin Hoffmann for a thourough review of The authors wish to thank Martin Hoffmann for a thourough review of
this document. this document.
11. References 13. References
11.1. Normative References 13.1. Normative References
[I-D.ietf-sidrops-https-tal] [I-D.ietf-sidrops-https-tal]
Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Huston, G., Weiler, S., Michaelson, G., Kent, S., and T.
Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Bruijnzeels, "Resource Public Key Infrastructure (RPKI)
Trust Anchor Locator", draft-ietf-sidrops-https-tal-05 Trust Anchor Locator", draft-ietf-sidrops-https-tal-08
(work in progress), October 2018. (work in progress), April 2019.
[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>.
[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>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<https://www.rfc-editor.org/info/rfc6482>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
<https://www.rfc-editor.org/info/rfc6486>. <https://www.rfc-editor.org/info/rfc6486>.
[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>.
[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
Authority (CA) Key Rollover in the Resource Public Key
Infrastructure (RPKI)", BCP 174, RFC 6489,
DOI 10.17487/RFC6489, February 2012,
<https://www.rfc-editor.org/info/rfc6489>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication
Protocol for the Resource Public Key Infrastructure Protocol for the Resource Public Key Infrastructure
(RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017, (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017,
<https://www.rfc-editor.org/info/rfc8181>. <https://www.rfc-editor.org/info/rfc8181>.
[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 13.2. Informative References
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
Authors' Addresses Authors' Addresses
Tim Bruijnzeels Tim Bruijnzeels
NLnet Labs NLnet Labs
 End of changes. 72 change blocks. 
440 lines changed or deleted 249 lines changed or added

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