< draft-ietf-sidr-res-certs-14.txt   draft-ietf-sidr-res-certs-15.txt >
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: Standards Track R. Loomans Intended status: Standards Track R. Loomans
Expires: April 29, 2009 APNIC Expires: May 21, 2009 APNIC
October 26, 2008 November 17, 2008
A Profile for X.509 PKIX Resource Certificates A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-14 draft-ietf-sidr-res-certs-15
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 29, 2009. This Internet-Draft will expire on May 21, 2009.
Abstract Abstract
This document defines a standard profile for X.509 certificates for This document defines a standard profile for X.509 certificates for
the purposes of supporting validation of assertions of "right-of-use" the purposes of supporting validation of assertions of "right-of-use"
of an Internet Number Resource (IP Addresses and Autonomous System of an Internet Number Resource (IP Addresses and Autonomous System
Numbers). This profile is used to convey the issuer's authorization Numbers). This profile is used to convey the issuer's authorization
of the subject to be regarded as the current holder of a "right-of- of the subject to be regarded as the current holder of a "right-of-
use" of the IP addresses and AS numbers that are described in the use" of the IP addresses and AS numbers that are described in the
issued certificate. issued certificate.
skipping to change at page 3, line 10 skipping to change at page 3, line 10
5.3. Certificate Extension Attributes in Certificate 5.3. Certificate Extension Attributes in Certificate
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Resource Certificate Validation . . . . . . . . . . . . . . . 21 6. Resource Certificate Validation . . . . . . . . . . . . . . . 21
6.1. Resource Extension Validation . . . . . . . . . . . . . . 22 6.1. Resource Extension Validation . . . . . . . . . . . . . . 22
6.2. Resource Certification Path Validation . . . . . . . . . . 23 6.2. Resource Certification Path Validation . . . . . . . . . . 23
6.3. Trust Anchors for Resource Certificates . . . . . . . . . 24 6.3. Trust Anchors for Resource Certificates . . . . . . . . . 24
6.3.1. Distribution Format of Default Trust Anchor 6.3.1. Distribution Format of Default Trust Anchor
Material . . . . . . . . . . . . . . . . . . . . . . . 25 Material . . . . . . . . . . . . . . . . . . . . . . . 25
7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 28 7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11.1. Normative References . . . . . . . . . . . . . . . . . . . 32 11.1. Normative References . . . . . . . . . . . . . . . . . . . 32
11.2. Informative References . . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. Example Resource Certificate . . . . . . . . . . . . 33 Appendix A. Example Resource Certificate . . . . . . . . . . . . 33
Appendix B. Example Certificate Revocation List . . . . . . . . . 35 Appendix B. Example Certificate Revocation List . . . . . . . . . 36
Appendix C. Cryptographic Message Syntax Profile for RPKI Appendix C. Cryptographic Message Syntax Profile for RPKI
Trust Anchor Material . . . . . . . . . . . . . . . . 37 Trust Anchor Material . . . . . . . . . . . . . . . . 37
C.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 37 C.1. Signed-Data ContentType . . . . . . . . . . . . . . . . . 37
C.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 38 C.1.1. encapContentInfo . . . . . . . . . . . . . . . . . . . 38
C.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 39 C.1.2. signerInfos . . . . . . . . . . . . . . . . . . . . . 39
C.2. RTA Validation . . . . . . . . . . . . . . . . . . . . . . 41 C.2. RTA Validation . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 44
1. Introduction 1. Introduction
skipping to change at page 10, line 32 skipping to change at page 10, line 32
associated with certificates issued by this Issuer. This profile associated with certificates issued by this Issuer. This profile
uses the URI form of object identification. The preferred URI access uses the URI form of object identification. The preferred URI access
mechanism is a single RSYNC URI ("rsync://") [rsync] that references mechanism is a single RSYNC URI ("rsync://") [rsync] that references
a single inclusive CRL for each issuer. a single inclusive CRL for each issuer.
In this profile the certificate issuer is also the CRL issuer, In this profile the certificate issuer is also the CRL issuer,
implying at the CRLIssuer field MUST be omitted, and the implying at the CRLIssuer field MUST be omitted, and the
distributionPoint field MUST be present. The Reasons field MUST be distributionPoint field MUST be present. The Reasons field MUST be
omitted. omitted.
The distributionPoint MUST contain general names, and MUST NOT The distributionPoint MUST contain GeneralNames, and MUST NOT contain
contain a nameRelativeToCRLIssuer. The type of the general name MUST a nameRelativeToCRLIssuer. The form of the generalName MUST be of
be of type URI. type URI.
In this profile, the scope of the CRL is specified to be all In this profile, the scope of the CRL is specified to be all
certificates issued by this CA issuer. certificates issued by this CA issuer.
The sequence of distributionPoint values MUST contain only a single The sequence of distributionPoint values MUST contain only a single
DistributionPointName set. The DistributionPointName set MAY contain DistributionPointName set. The DistributionPointName set MAY contain
more than one URI value. An RSYNC URI MUST be present in the more than one URI value. An RSYNC URI MUST be present in the
DistributionPointName set, and reference the most recent instance of DistributionPointName set, and reference the most recent instance of
this issuer's certificate revocation list. Other access form URIs this issuer's certificate revocation list. Other access form URIs
MAY be used in addition to the RSYNC URI. MAY be used in addition to the RSYNC URI.
skipping to change at page 11, line 20 skipping to change at page 11, line 20
single reference object to publication location of the immediate single reference object to publication location of the immediate
superior certificate MUST be used, except in the case where a CA superior certificate MUST be used, except in the case where a CA
distributes its public key in the form of a "self-signed" distributes its public key in the form of a "self-signed"
certificate, in which case the AIA field SHOULD be omitted. certificate, in which case the AIA field SHOULD be omitted.
This profile uses a URI form of object identification. The preferred This profile uses a URI form of object identification. The preferred
URI access mechanisms is "rsync", and an RSYNC URI MUST be specified URI access mechanisms is "rsync", and an RSYNC URI MUST be specified
with an accessMethod value of id-ad-caIssuers. The URI MUST with an accessMethod value of id-ad-caIssuers. The URI MUST
reference the point of publication of the certificate where this reference the point of publication of the certificate where this
issuer is the subject (the issuer's immediate superior certificate). issuer is the subject (the issuer's immediate superior certificate).
Other access method URIs referencing the same object MAY also be Other accessMethod URIs referencing the same object MAY also be
included in the value sequence of this extension. included in the value sequence of this extension.
When an Issuer re-issues a CA certificate, the subordinate When an Issuer re-issues a CA certificate, the subordinate
certificates need to reference this new certificate via the AIA certificates need to reference this new certificate via the AIA
field. In order to avoid the situation where a certificate re- field. In order to avoid the situation where a certificate re-
issuance necessarily implies a requirement to re-issue all issuance necessarily implies a requirement to re-issue all
subordinate certificates, CA Certificate issuers SHOULD use a subordinate certificates, CA Certificate issuers SHOULD use a
persistent URL name scheme for issued certificates. This implies persistent URL name scheme for issued certificates. This implies
that re-issued certificates overwrite previously issued certificates that re-issued certificates overwrite previously issued certificates
to the same subject in the publication repository, and use the same to the same subject in the publication repository, and use the same
skipping to change at page 11, line 51 skipping to change at page 11, line 51
This extension (SIA) identifies the location of information and This extension (SIA) identifies the location of information and
services relating to the subject of the certificate in which the SIA services relating to the subject of the certificate in which the SIA
extension appears. Where the Subject is a CA in this profile, this extension appears. Where the Subject is a CA in this profile, this
information and service collection will include all current valid information and service collection will include all current valid
certificates that have been issued by this subject that are signed certificates that have been issued by this subject that are signed
with the subject's corresponding private key. with the subject's corresponding private key.
This profile uses a URI form of location identification. The This profile uses a URI form of location identification. The
preferred URI access mechanism is "rsync", and an RSYNC URI MUST be preferred URI access mechanism is "rsync", and an RSYNC URI MUST be
specified, with an access method value of id-ad-caRepository when the specified, with an accessMethod value of id-ad-caRepository when the
subject of the certificate is a CA. The RSYNC URI MUST reference an subject of the certificate is a CA. The RSYNC URI MUST reference an
object collection rather than an individual object and MUST use a object collection rather than an individual object and MUST use a
trailing '/' in the URI. trailing '/' in the URI.
Other access method URIs that reference the same location MAY also be Other accessMethod URIs that reference the same location MAY also be
included in the value sequence of this extension. The ordering of included in the value sequence of this extension. The ordering of
URIs in this sequence reflect the subject's relative preferences for URIs in this sequence reflect the subject's relative preferences for
access methods, with the first method in the sequence being the most access methods to be used by parties for retrieval of objects from
preferred. the associated repository publication point, with the first method in
the accessMethod sequence being the most preferred.
This extension MUST be present when the subject is a CA, and is non- This extension MUST be present when the subject is a CA, and is non-
critical. critical.
For End Entity (EE) certificates, where the subject is not a CA, this For End Entity (EE) certificates, where the subject is not a CA, this
extension MAY be present, and is non-critical. If present, it either extension MAY be present, and is non-critical. If present, it either
references the location where objects signed by the private key references the location where objects signed by the private key
associated with the EE certificate can be accessed, or, in the case associated with the EE certificate can be accessed, or, in the case
of single-use EE certificates it references the location of the of single-use EE certificates it references the location of the
single object that has been signed by the corresponding private key. single object that has been signed by the corresponding private key.
skipping to change at page 12, line 45 skipping to change at page 12, line 46
id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 } id-ad-signedObject OBJECT IDENTIFIER ::= { id-ad 11 }
This profile requires the use of repository publication manifests This profile requires the use of repository publication manifests
[ID.sidr-manifests] to list all signed objects that are deposited in [ID.sidr-manifests] to list all signed objects that are deposited in
the repository publication point associated with a CA or an EE. The the repository publication point associated with a CA or an EE. The
publication point of the manifest for a CA or EE is placed in the SIA publication point of the manifest for a CA or EE is placed in the SIA
extension of the CA or EE certificate. This profile uses a URI form extension of the CA or EE certificate. This profile uses a URI form
of manifest identification for the accessLocation. The preferred URI of manifest identification for the accessLocation. The preferred URI
access mechanisms is "rsync", and an RSYNC URI MUST be specified. access mechanisms is "rsync", and an RSYNC URI MUST be specified.
Other accessDescription fields may exist with this id-ad-Manifest Other accessDescription fields may exist for the id-ad-rpkiManifest
accessMethod, where the accessLocation value indicates alternate URI accessMethod, where the accessLocation value indicates alternate URI
access mechanisms for the same manifest object. access mechanisms for the same manifest object.
id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 } id-ad-rpkiManifest OBJECT IDENTIFIER ::= { id-ad 10 }
CA certificates MUST include in the SIA an accessMethod OID of id-ad- CA certificates MUST include in the SIA an accessMethod OID of id-ad-
rpkiManifest, where the associated accessLocation refers to the rpkiManifest, where the associated accessLocation refers to the
subject's published manifest object as an object URL. subject's published manifest object as an object URL.
When an EE certificate is intended for use in verifying multiple When an EE certificate is intended for use in verifying multiple
objects, EE certificate MUST include in the SIA an access method OID objects, EE certificate MUST include in the SIA an accessMethod OID
of id-ad-rpkiManifest, where the associated access location refers to of id-ad-rpkiManifest, where the associated accessLocation refers to
the publication point of the objects that are verified using this EE the EE's published manifest object as an object URL.
certificate.
When an EE certificate is used to verify a single published object, When an EE certificate is used to verify a single published object,
the EE certificate MUST include in the SIA an access method OID of the EE certificate MUST include in the SIA an accessMethod OID of id-
id-ad-signedObject, where the associated access location refers to ad-signedObject, where the associated accessLocation refers to the
the publication point of the single object that is verified using publication point of the single object that is verified using this EE
this EE certificate. In this case, the SIA MUST NOT include the certificate. In this case, the SIA MUST NOT include the accessMethod
access method OID of id-ad-rpkiManifest. OID of id-ad-rpkiManifest.
3.9.8. Certificate Policies 3.9.8. Certificate Policies
This extension MUST reference the Resource Certificate Policy, using This extension MUST reference the Resource Certificate Policy, using
the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field the OID Policy Identifier value of "1.3.6.1.5.5.7.14.2". This field
MUST be present and MUST contain only this value for Resource MUST be present and MUST contain only this value for Resource
Certificates. Certificates.
No PolicyQualifiers are defined for use with this policy and thus No PolicyQualifiers are defined for use with this policy and thus
none must be included in this extension. none must be included in this extension.
skipping to change at page 20, line 30 skipping to change at page 20, line 30
This field (SIA) identifies the location of information and This field (SIA) identifies the location of information and
services relating to the subject of the certificate in which services relating to the subject of the certificate in which
the SIA extension appears. the SIA extension appears.
Where the subject is a CA in this profile, this information and Where the subject is a CA in this profile, this information and
service collection will include all current valid certificates service collection will include all current valid certificates
that have been issued by this subject that are signed with the that have been issued by this subject that are signed with the
subject's corresponding private key. subject's corresponding private key.
This profile uses a URI form of location identification. An This profile uses a URI form of location identification. An
RSYNC URI MUST be specified, with an access method value of id- RSYNC URI MUST be specified, with an accessMethod value of id-
ad-caRepository when the subject of the certificate is a CA. ad-caRepository when the subject of the certificate is a CA.
The RSYNC URI MUST reference an object collection rather than The RSYNC URI MUST reference an object collection rather than
an individual object and MUST use a trailing '/' in the URI. an individual object and MUST use a trailing '/' in the URI.
Other access method URIs that reference the same location MAY Other accessMethod URIs that reference the same location MAY
also be included in the value sequence of this extension. The also be included in the value sequence of this extension. The
ordering of URIs in this sequence reflect the subject's ordering of URIs in this sequence reflect the subject's
relative preferences for access methods, with the first method relative preferences for access methods, with the first method
in the sequence being the most preferred by the Subject. in the sequence being the most preferred by the Subject.
A request for a CA certificate MUST include in the SIA of the A request for a CA certificate MUST include in the SIA of the
request the id-ad-caRepository access method, and also MUST request the id-ad-caRepository accessMethod, and also MUST
include in the SIA of the request the accessMethod OID of id- include in the SIA of the request the accessMethod OID of id-
ad-rpkiManifest, where the associated accessLocation refers to ad-rpkiManifest, where the associated accessLocation refers to
the subject's published manifest object as an object URL. the subject's published manifest object as an object URL.
This field MAY be present when the subject is a EE. If it is This field MAY be present when the subject is a EE. If it is
present the field value SHOULD be honored by the CA. If the CA present the field value SHOULD be honored by the CA. If the CA
is not able to honor the requested field value, then the CA is not able to honor the requested field value, then the CA
MUST reject the Certificate Request. If it is not present the MUST reject the Certificate Request. If it is not present the
CA SHOULD honor this request and omit the SIA from the issued CA SHOULD honor this request and omit the SIA from the issued
certificate. If the CA is not able to honor the request to certificate. If the CA is not able to honor the request to
omit the SIA, then the CA MUST reject the Certificate Request. omit the SIA, then the CA MUST reject the Certificate Request.
When an EE certificate is intended for use in verifying When an EE certificate is intended for use in verifying
multiple objects, the certificate request for the EE multiple objects, the certificate request for the EE
certificate MUST include in the SIA of the request an access certificate MUST include in the SIA of the request an
method OID of id-ad-signedObjectRepository, and also MUST accessMethod OID of id-ad-signedObjectRepository, and also MUST
include in the SIA of the request an access method OID of id- include in the SIA of the request an accessMethod OID of id-ad-
ad-rpkiManifest, where the associated access location refers to rpkiManifest, where the associated access location refers to
the publication point of the objects that are verified using the publication point of the manifest object describing all
this EE certificate. objects that are verified using this EE certificate.
When an EE certificate is used to sign a single published When an EE certificate is used to sign a single published
object, the certificate request for the EE certificate MUST object, the certificate request for the EE certificate MUST
include in the SIA of the request an access method OID of id- include in the SIA of the request an accessMethod OID of id-ad-
ad-signedObject, where the associated access location refers to signedObject, where the associated accessLocation refers to the
the publication point of the single object that is verified publication point of the single object that is verified using
using this EE certificate, and MUST NOT include an id-ad- this EE certificate, and MUST NOT include an id-ad-rpkiManifest
rpkiManifest access method OID in the SIA of the request. accessMethod OID in the SIA of the request.
In the case when the EE certificate is to be used exclusively In the case when the EE certificate is to be used exclusively
to sign one or more unpublished objects, such that the all to sign one or more unpublished objects, such that the all
signed objects will not be published in any RPKI repository, signed objects will not be published in any RPKI repository,
then the SIA SHOULD be omitted from the request. then the SIA SHOULD be omitted from the request.
CRLDistributionPoints CRLDistributionPoints
This field is assigned by the CA and MUST be omitted in this This field is assigned by the CA and MUST be omitted in this
profile. profile.
skipping to change at page 24, line 19 skipping to change at page 24, line 19
maintained cache, maintained by a regular synchronization across the maintained cache, maintained by a regular synchronization across the
distributed publication repository structure. distributed publication repository structure.
There exists the possibility of encountering certificate paths that There exists the possibility of encountering certificate paths that
are arbitrarily long, or attempting to generate paths with loops as are arbitrarily long, or attempting to generate paths with loops as
means of creating a potential DOS attack on a relying party. Some means of creating a potential DOS attack on a relying party. Some
further heuristics may be required to halt the certification path further heuristics may be required to halt the certification path
validation process in order to avoid some of the issues associated validation process in order to avoid some of the issues associated
with attempts to validate such structures. It is suggested that with attempts to validate such structures. It is suggested that
implementations of Resource Certificate validation MAY halt with a implementations of Resource Certificate validation MAY halt with a
validation failure if the certification path length exceeds a pre- validation failure if the certification path length exceeds a locally
determined configuration parameter. defined configuration parameter.
6.3. Trust Anchors for Resource Certificates 6.3. Trust Anchors for Resource Certificates
The default trust model for the resource certificate PKI maps to the The default trust model for the resource certificate PKI maps to the
extant public resource allocation system, comprised of IANA, RIRs, extant public resource allocation system, comprised of IANA, RIRs,
NIRs (in some regions) and LIRs. This is a strict hierarchy, in that NIRs (in some regions) and LIRs. This is a strict hierarchy, in that
any number resource and a corresponding recipient entity has only one any number resource and a corresponding recipient entity has only one
'parent' issuing registry for that resource. Moreover, the issuing 'parent' issuing registry for that resource. Moreover, the issuing
registry is not a direct or indirect subordinate recipient entity of registry is not a direct or indirect subordinate recipient entity of
the recipient entity in question (i.e., there are no loops in the the recipient entity in question (i.e., there are no loops in the
model). model).
Nonetheless, as in any PKI, selection of one or more entities as Nonetheless, as in any PKI, selection of one or more entities as
trust anchor is a task undertaken by each relying party. The trust anchor is a task undertaken by each relying party. The
structure of the resource certificate profile admits the same variety structure of the resource certificate profile admits the same variety
of trust models as PKIX (and X.509) standards. There is only one of trust models as PKIX (and X.509) standards. There is only one
additional caveat on the general applicability of trust models, additional caveat on the general applicability of trust models,
namely that in forming a validation path to a CA immediately below a namely that in forming a validation path to a CA, the sequence of
trust anchor, the sequence of certificates MUST preserve the resource resource certificates MUST preserve the resource extension validation
extension validation property, as described in Section 6.1. property, as described in Section 6.1. [RFC3779] establishes this
Section 6.1. requirement for certificate path validation when the extensions
defined therein are employed. This poses a problem in the RPKI, as
The trust anchor information, describing a CA that serves as a trust explained below.
anchor, includes the following:
1. the trust anchor name,
2. the public key algorithm, Based on experience, a top level resource certificate held by a
3. the trust anchor's public key, and registry will change several times a year, in response to receipt of
additional resource allocations. This makes such certificates poor
candidates as trust anchors, since one usually views a trust anchor
as a long-lived set of data. Yet [RFC3779] requires that the trust
anchor used for validation of certificates contains resource
extensions MUST itself contain such extensions, and the extensions
must be a superset of extensions contained in subordinate
certificates in the path.
4. optionally, parameters associated with the public key. This observation motivates a two-tier trust anchor model for the
RPKI. The top tier trust anchor for each RIR (and IANA) will be a
self-signed certificate that contains no resource extensions. It is
a resource certificate as defined in this document, except for that
one omission. This certificate will be referred to as a "registry
root certificate" (RRC) or registry TA certificate. (Note that the
term "registry" here is not intended to preclude use of this
mechanism by other than the RIRs and the IANA.) Under this
certificate one EE certificate is issued; that certificate also
contains no resource extensions. The EE certificate is used to
validate a CMS signed object that contains a self-signed certificate
that itself contains resource extensions, and this self-signed
certificate acts as a TA for resource certificate path validation.
This latter certificate will be referred to as an RPKI TA
(certificate).
The trust anchor information may be provided to the path processing Both the registry TA and the RPKI TA will be represented as self-
procedure in the form of a self-signed certificate. signed certificates, consistent with the wide-spread convention that
is allowed (thought not mandated) by [RFC5280]. Following this
convention makes it easier to reuse existing PKI software (e.g.,
OpenSSL) to process this trust anchor material.
6.3.1. Distribution Format of Default Trust Anchor Material 6.3.1. Distribution Format of Default Trust Anchor Material
In the RPKI, the certificate framework corresponds to the hierarchies In the RPKI, the certificate framework corresponds to the hierarchies
of the resource distribution function. In consideration of this, it of the resource distribution function. In consideration of this, it
is reasonable to nominate to relying parties a default set of trust is reasonable to nominate to relying parties a default set of trust
anchors for the RPKI that correspond to the entities who operate at anchor pairs (registry TA and RPKI TA) for the RPKI that correspond
the upper levels of the associated resource allocation hierarchy. to the entities who operate at the upper levels of the associated
The corresponding nominated trust anchor CA(s) should therefore map, resource allocation hierarchy. The corresponding nominated trust
in some fashion, to apex point(s) of the hierarchical resource anchor CA(s) should therefore map, in some fashion, to apex point(s)
distribution structure. of the hierarchical resource distribution structure.
The characteristics of a trust anchor framework for the RPKI includes The characteristics of a trust anchor framework for the RPKI includes
the following considerations: the following considerations:
* The entity or entities that issue proposed trust anchor * The entity or entities that issue proposed trust anchor
material for the RPKI should be as close as possible to the material for the RPKI should be as close as possible to the
apex of the associated resource distribution hierarchy. apex of the associated resource distribution hierarchy.
* Such trust anchor material SHOULD be long-lived. As it can be * Such trust anchor material SHOULD be long-lived. As it can be
reasonably anticipated that default trust anchor material would reasonably anticipated that default trust anchor material would
skipping to change at page 25, line 47 skipping to change at page 26, line 17
information or actions of which the entity has no direct information or actions of which the entity has no direct
knowledge, nor is in possession of a current definitive record knowledge, nor is in possession of a current definitive record
of such actions. Entities who propose themselves in a role of of such actions. Entities who propose themselves in a role of
a trust anchor issuer SHOULD be able to point to corroborative a trust anchor issuer SHOULD be able to point to corroborative
material supporting the assertion that they are legitimate material supporting the assertion that they are legitimate
authorities for the information for which they are representing authorities for the information for which they are representing
themselves as a trust anchor for relying parties. themselves as a trust anchor for relying parties.
An entity offering itself as a putative trust anchor for a part of An entity offering itself as a putative trust anchor for a part of
the RPKI is required to regularly publish an RPKI CA certificate at a the RPKI is required to regularly publish an RPKI CA certificate at a
stable URL, and to publish this URL as distributed trust anchor stable URL, and to publish at this URL trust anchor material, as
material, as follows: follows:
* The entity issues an RPKI self-signed "root" CA certificate * The entity issues a registry root certificate (self-signed).
that is used as the apex of an RPKI certificate validation This certificate is used to bootstrap validation of an RPKI TA
tree. This certificate MUST meet all of the criteria (self-signed) certificate, as described below. The RPKI TA
established in Section 3 of this document for a self-signed certificate MUST meet all of the criteria established in
RPKI certificate. This certificate MUST be reissued Section 3 of this document for a self-signed RPKI certificate.
periodically, prior to its expiration, and MUST be reissued This certificate MUST be reissued periodically, prior to its
upon any change in the resource set that has been allocated to expiration, and MUST be reissued upon any change in the
the entity operating this CA. The validity interval of this resource set that has been allocated to the entity operating
certificate SHOULD reflect the anticipated period of changes to this CA. The validity interval of this certificate SHOULD
the entity's resource set . reflect the anticipated period of changes to the entity's
resource set .
* The entity maintains a trust anchor key pair that is distinct * The entity maintains a trust anchor key pair that is distinct
from the key pair represented in the self-signed RPKI CA noted from the key pair represented in the RPKI TA certificate noted
above. above.
* The entity issues a self-signed CA certificate [RFC5280] (that * The entity issues a (self-signed) CA certificate that contains
contains no RFC 3779 extension) where the subject public key in no RFC 3779 extension. This is called the RPKI TA certificate.
the certificate is the public key of the trust anchor and the
certificate is signed using the corresponding private key of
trust anchor key pair. This is called the TA CA certificate.
This certificate MUST have the keyCertSign sign bit set in the This certificate MUST have the keyCertSign sign bit set in the
key usage extension, and the CA flag set in the basic key usage extension, and the CA flag set in the basic
constraints extension, no AIA value and no CRLDP value. The constraints extension, no AIA value and no CRLDP value. The
validity period of this certificate should be very long, as is validity period of this certificate should be very long, as is
the norm for trust anchor material. The SIA of this the norm for trust anchor material. The SIA of this
certificate references a publication point where the CRL and certificate references a publication point where the CRL and
the CMS structure defined below are published. the CMS structure defined below are published.
* The trust anchor (TA) issues an EE certificate (a TA EE * The registry trust anchor issues an EE certificate (a registry
certificate) with a validity period identical to the validity TA EE certificate) with a validity period identical to the
period of its RPKI self-signed "root" CA certificate. This EE validity period of its RPKI TA certificate. This EE
certificate MUST have the digitalSignature bit set, and this certificate MUST have the digitalSignature bit set, and this
MUST be the only bit set to TRUE. There is no BasicConstraints MUST be the only bit set to TRUE in the key usage extension.
extension in this certificate. The validity period of this TA There is no BasicConstraints extension in this certificate.
EE certificate SHOULD be aligned to the validity period of the
RPKI self-signed "root" CA certificate.
* The TA CA regularly issues a CRL. The CRL issuance cycle The validity period of this registry TA EE certificate SHOULD
SHOULD be shorter than the validity period for the RPKI self- be aligned to the validity period of the registry TA
signed "root" certificate. certificate.
* Each time the RPKI self-signed "root" certificate is re-issued, * The registry TA regularly issues a CRL. The CRL issuance cycle
or prior to the expiration of the TA EE certificate, the TA SHOULD be shorter than the validity period for the RPKI TA
certificate.
* Each time an RPKI TA certificate is re-issued, or prior to the
expiration of the registry TA EE certificate, the registry
generates a Cryptographic Message Syntax (CMS) [RFC3852] generates a Cryptographic Message Syntax (CMS) [RFC3852]
signed-data object, the payload of which is an RPKI self-signed signed-data object, the payload of which is an RPKI TA
"root" certificate. The object is CMS-signed with the private certificate. The object is CMS-signed with the private key
key of the TA EE certificate. The TA EE certificate is corresponding to the registry TA EE certificate. The registry
included as a CMS signed attribute in the CMS object. The TA TA EE certificate is included as a CMS signed attribute in the
CA certificate and the associated CRL are not to be included in CMS object. The registry TA certificate and the associated CRL
the CMS object. The format of the CMS object is specified in are not to be included in the CMS object. The format of the
Appendix C. The CMS object is published at the location CMS object is specified in Appendix C. The CMS object is
referenced in the SIA of the TA CA certificate. published at the location referenced in the SIA of the TA CA
certificate.
* The entity publicly distributes the TA CA certificate as its * The entity publicly distributes the registry TA certificate as
trust anchor material, in an out-of-band fashion, e.g., as part its trust anchor material, in an out-of-band fashion, e.g., as
of widely distributed relying party software. part of widely-distributed relying party software.
Relying Parties can assemble the default trust anchor collection by Relying Parties can assemble the default trust anchor collection by
using the TA CA certificate for each nominated trust anchor: using the registry TA certificate for each nominated trust anchor:
* The TA CA's CRL and CMS objects can be retrieved from the * The TA's CRL and CMS objects can be retrieved from the
publication point referenced by the SIA in the TA CA publication point referenced by the SIA in the registry TA
certificate. certificate.
* The CRL can be verified against the TA CA certificate. * The CRL can be verified against the registry TA certificate.
* The CMS signature can be verified using the included TA EE * The CMS signature can be verified using the included registry
certificate together with the retrieved CRL and the self-signed TA EE certificate together with the retrieved CRL and the
TA CA certificate. (self-signed) TA certificate.
* The relying party can then load the enclosed RPKI self-signed * The relying party can then load the enclosed RPKI TA CA
CA certificate as a trust anchor for RPKI validation for those certificate as a trust anchor for validation fof those
resources described in the IP Resource extensions [RFC3779] of resources described in the IP Resource extensions [RFC3779] of
this RPKI certificate. this RPKI certificate.
Relying Parties SHOULD perform this retrieval and validation Relying Parties SHOULD perform this retrieval and validation
operation at intervals no less frequent than the nextUpdate time of operation at intervals no less frequent than the nextUpdate time of
the published TA CA CRL, and SHOULD perform the retrieval operation the published TA CA CRL, and SHOULD perform the retrieval operation
prior to the expiration of the TA EE certificate, or upon revocation prior to the expiration of the registry TA EE certificate, or upon
of the TA EE certificate that is used to verify the CMS object that revocation of the registry TA EE certificate that is used to verify
holds the trust anchor's current RPKI self-signed CA certificate. the CMS object that holds the trust anchor's current RPKI TA CA
certificate.
If a trust anchor chooses to reissue its RPKI self- signed CA If a trust anchor chooses to reissue its RPKI TA CA certificate
certificate before the expiration of that certificate, it MUST before the expiration of that certificate, it MUST perform the follow
perform the follow actions: revise the nextUpdate time of the TA CA's actions: revise the nextUpdate time of the registry TA's CRL to
CRL to reflect the issue date for the new TA EE certificate, issue a reflect the issue date for the new registry TA EE certificate, issue
new TA EE certificate and a new CMS object with the new RPKI self- a new registry TA EE certificate and a new CMS object with the new
signed CA certificate, and revoke the old TA EE certificate at the RPKI TA CA certificate, and revoke the old TA EE certificate at the
nextUpdate time in the next issued CRL. This revocation will provide nextUpdate time in the next issued CRL. This revocation will provide
an indication to relying parties to perform the retrieval operation an indication to relying parties to perform the retrieval operation
of the RPKI self-signed CA certificate at a time earlier than the of the RPKI TA CA certificate at a time earlier than the normal
normal update cycle time. . update cycle time.
7. Design Notes 7. Design Notes
The following notes provide some additional commentary on the The following notes provide some additional commentary on the
considerations that lie behind some of the design choices that were considerations that lie behind some of the design choices that were
made in the design of this certificate profile. These notes do not made in the design of this certificate profile. These notes do not
constitute a formal part of the profile specification, and the constitute a formal part of the profile specification, and the
interpretation of key words as defined in RFC2119 are not applicable interpretation of key words as defined in RFC2119 are not applicable
in this section of the document. in this section of the document.
skipping to change at page 31, line 47 skipping to change at page 32, line 13
conveyed in a certificate is no better than the information in the conveyed in a certificate is no better than the information in the
allocation and assignment databases. allocation and assignment databases.
9. IANA Considerations 9. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA [Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this document.] considerations stated in this document.]
10. Acknowledgements 10. Acknowledgements
The authors would like to acknowledge the valued contributions from The authors would like to particularly acknowledge the valued
Stephen Kent, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo contribution from Stephen Kent in reviewing this document and
Patara and Rob Austein in the preparation and subsequent review of proposing numerous sections of text that have been incorporated into
this document. The document also reflects review comments received the text. The authors also acknowledge the contributions of Robert
from Sean Turner and David Cooper. Kisteleki, Randy Bush, Russ Housley, Ricardo Patara and Rob Austein
in the preparation and subsequent review of this document. The
document also reflects review comments received from Sean Turner and
David Cooper.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and
J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", J. Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES",
skipping to change at page 33, line 32 skipping to change at page 33, line 49
Nicholas, "Internet X.509 Public Key Infrastructure: Nicholas, "Internet X.509 Public Key Infrastructure:
Certification Path Building", RFC 4158, September 2005. Certification Path Building", RFC 4158, September 2005.
[rsync] Tridgell, A., "rsync", April 2006, [rsync] Tridgell, A., "rsync", April 2006,
<http://samba.anu.edu.au/rsync/>. <http://samba.anu.edu.au/rsync/>.
Appendix A. Example Resource Certificate Appendix A. Example Resource Certificate
The following is an example Resource Certificate. The following is an example Resource Certificate.
Certificate Name: hu9fdDBq60mrk7cPRuX2DYuXSRQ-3.cer Certificate Name: 9JfgAEcq7Q-47IwMC5CJIJr6EJs.cer
Data: Data:
Version: 3
Serial: 3 Version: 3 (0x2)
Signature Algorithm: Hash: SHA256, Encryption: RSA Serial: 1500 (0x5dc)
Issuer: CN=Demo Production APNIC CA - Not for real use, Signature Algorithm: SHA256WithRSEEncryption
E=ca@apnic.net Issuer: CN=APNIC Production-CVPQSgUkLy7pOXdNeVWGvnFX_0s
Validity: Validity
Not Before: Thu Jul 27 06:34:04 2006 GMT Not Before: Oct 25 12:50:00 2008 GMT
Not After: Fri Jul 27 06:34:04 2007 GMT Not After : Jan 31 00:00:00 2010 GMT
Subject: CN=APNIC own-use network resources Subject: CN=A91872ED
Subject Key Identifier:
86:ef:5f:74:30:6a:eb:49:ab:93:b7:0f:46:e5:f6:0d:
8b:97:49:14
Subject Key Identifier g(SKI):
hu9fdDBq60mrk7cPRuX2DYuXSRQ
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: rsaEncryption Public Key Algorithm: rsaEncryption
RSA Public Key: Modulus: RSA Public Key: (2048 bit)
c1:25:a1:b0:db:89:83:a0:fc:f1:c0:e4:7b:93:76:c1: Modulus (2048 bit):
59:b7:0d:ac:25:25:ed:88:ce:00:03:ea:99:1a:9a:2a: 00:bb:fb:4a:af:a4:b9:dc:d0:fa:6f:67:cc:27:39:
0e:10:2e:5f:c0:45:87:47:81:7b:1d:4d:44:aa:65:a3: 34:d1:80:40:37:de:88:d1:64:a2:f1:b3:fa:c6:7f:
f8:07:84:32:ea:04:70:27:05:2b:79:26:e6:e6:3a:cb: bb:51:df:e1:c7:13:92:c3:c8:a2:aa:8c:d1:11:b3:
b2:9a:65:6c:c1:4e:d7:35:fb:f6:41:1e:8b:1c:b8:e4: aa:99:c0:ac:54:d3:65:83:c6:13:bf:0d:9f:33:2d:
5a:3a:d6:d0:7b:82:9a:23:03:f8:05:4c:68:42:67:fe: 39:9f:ab:5f:cd:a3:e9:a1:fb:80:7d:1d:d0:2b:48:
e7:45:d9:2c:a6:d1:b3:da:cf:ad:77:c5:80:d2:e3:1e: a5:55:e6:24:1f:06:41:35:1d:00:da:1f:99:85:13:
4d:e8:bf:a2:f2:44:10:b2:2f:61:bc:f4:89:31:54:7c: 26:39:24:c5:9a:81:15:98:fb:5f:f9:84:38:e5:d6:
56:47:d5:b1:c3:48:26:95:93:c9:6f:70:14:4d:ac:a5: 70:ce:5a:02:ca:dd:61:85:b3:43:2d:0b:35:d5:91:
c2:8e:3d:1f:6d:f8:d4:93:9d:14:c7:15:c7:34:8e:ba: 98:9d:da:1e:0f:c2:f6:97:b7:97:3e:e6:fc:c1:c4:
dd:70:b3:c2:2b:08:78:59:97:dd:e4:34:c7:d8:de:5c: 3f:30:c4:81:03:25:99:09:4c:e2:4a:85:e7:46:4b:
f7:94:6f:95:59:ba:29:65:f5:98:15:8f:8e:57:59:5d: 60:63:02:43:46:51:4d:ed:fd:a1:06:84:f1:4e:98:
92:1f:64:2f:b5:3d:69:2e:69:83:c2:10:c6:aa:8e:03: 32:da:27:ee:80:82:d4:6b:cf:31:ea:21:af:6f:bd:
d5:69:11:bd:0d:b5:d8:27:6c:74:2f:60:47:dd:2e:87: 70:34:e9:3f:d7:e4:24:cd:b8:e0:0f:8e:80:eb:11:
24:c2:36:68:2b:3c:fd:bd:22:57:a9:4d:e8:86:3c:27: 1f:bc:c5:7e:05:8e:5c:7b:96:26:f8:2c:17:30:7d:
03:ce:f0:03:2e:59:ce:05:a7:41:3f:2f:64:50:dd:e7 08:9e:a4:72:66:f5:ca:23:2b:f2:ce:54:ec:4d:d9:
RSA Public Key: Exponent: 65537 d9:81:72:80:19:95:57:da:91:00:d9:b1:e8:8c:33:
Basic Constraints: CA: TRUE 4a:9d:3c:4a:94:bf:74:4c:30:72:9b:1e:f5:8b:00:
Subject Info Access: 4d:e3
caRepository - rsync://repository.apnic.net/APNIC/ Exponent: 65537 (0x10001)
pvpjvwUeQix2e54X8fGbhmdYMo0/ X509v3 extensions:
q66IrWSGuBE7jqx8PAUHAlHCqRw/ X509v3 Subject Key Identifier:
hu9fdDBq60mrk7cPRuX2DYuXSRQ/ F4:97:E0:00:47:2A:ED:0F:B8:EC:8C:0C:0B:90:89:
Key Usage: keyCertSign, cRLSign 20:9A:FA:10:9B
CRL Distribution Points:
rsync://repository.apnic.net/APNIC/
pvpjvwUeQix2e54X8fGbhmdYMo0/
q66IrWSGuBE7jqx8PAUHAlHCqRw/
q66IrWSGuBE7jqx8PAUHAlHCqRw.crl
Authority Info Access: caIssuers -
rsync://repository.apnic.net/APNIC/
pvpjvwUeQix2e54X8fGbhmdYMo0/
q66IrWSGuBE7jqx8PAUHAlHCqRw.cer
Authority Key Identifier: Key Identifier:
ab:ae:88:ad:64:86:b8:11:3b:8e:ac:7c:3c:05:07:02:
51:c2:a9:1c
Authority Key Identifier: Key Identifier g(AKI):
q66IrWSGuBE7jqx8PAUHAlHCqRw
Certificate Policies: 1.3.6.1.5.5.7.14.2
IPv4: 192.0.2.0/24,
IPv6: 2001:DB8::/32
ASNum: 4608, 4777, 9545, 18366-18370
Signature:
c5:e7:b2:f3:62:cb:e3:bc:50:1e:6b:90:13:19:f4:5b:
4a:1c:1c:ab:b5:de:b1:a4:22:e0:28:f5:3b:d0:8c:59:
0f:85:f2:06:a6:ae:22:e6:d0:99:fe:cb:eb:1d:6a:e2:
a3:f1:a2:25:95:ec:a7:7d:96:35:dc:16:a7:2f:f5:b7:
11:ba:97:05:57:5f:5d:07:5a:c8:19:c8:27:d3:f7:a3: X509v3 Authority Key Identifier:
92:66:cb:98:2d:e1:7f:a8:25:96:ab:af:ed:87:02:28: keyid:09:53:D0:4A:05:24:2F:2E:E9:39:77:4D:79:
f5:ae:b6:e3:0c:f7:18:82:70:82:f4:76:54:06:b9:9f: 55:86:BE:71:57:FF:4B
e1:a5:f7:ae:72:dd:ee:f0:d4:d2:78:bb:61:73:cf:51:
26:9f:ea:e8:20:49:06:ba:0c:ac:1d:f6:07:b8:63:a0: X509v3 Key Usage: critical
4d:3d:8e:12:84:3a:d0:ec:94:7e:02:db:d4:85:cf:12: Certificate Sign, CRL Sign
5c:7b:12:1a:52:ab:3c:ba:00:f2:71:e7:f0:fd:b3:f4:
81:e8:a7:cb:07:ca:3a:a4:24:fe:dc:bb:51:16:6a:28: X509v3 Basic Constraints: critical
33:40:a4:64:60:75:0e:c8:06:c8:5f:e5:98:be:16:a3: CA:TRUE
bc:19:e7:b3:4f:00:0a:8e:81:33:dd:4c:a0:fb:f5:1c:
1f:1d:3f:b5:90:8b:ec:98:67:76:95:56:8a:94:45:54: X509v3 CRL Distribution Points:
52:3d:1c:69:4c:6f:8a:9f:09:ec:ef:b0:a9:bc:cf:9d URI:rsync://rpki.apnic.net/repository/A3C38A24
D60311DCAB08F31979BDBE39/CVPQSgUkLy7pOXdNe
VWGvnFX_0s.crl
Authority Information Access:
CA Issuers - URI:rsync://rpki.apnic.net/repos
itory/8BDFC7DED5FD11DCB14CF4B1A703F9B7/CVP
QSgUkLy7pOXdNeVWGvnFX_0s.cer
X509v3 Certificate Policies: critical
Policy: 1.3.6.1.5.5.7.14.2
Subject Information Access:
CA Repository - URI:rsync://rpki.apnic.net/mem
ber_repository/A91872ED/06A83982887911DD81
3F432B2086D636/
Manifest - URI:rsync://rpki.apnic.net/member_r
epository/A91872ED/06A83982887911DD813F432
B2086D636/9JfgAEcq7Q-47IwMC5CJIJr6EJs.mft
AutonomousSysNum: critical
Autonomous System Numbers:
24021
38610
131072
131074
IPAddrBlock: critical
IPv4:
203.133.248.0/22
203.147.108.0/23
Signature Algorithm: sha256WithRSAEncryption
51:4c:77:e4:21:64:80:e9:35:30:20:9f:d8:4b:88:60:b8:1f:
73:24:9d:b5:17:60:65:6a:28:cc:43:4b:68:97:ca:76:07:eb:
dc:bd:a2:08:3c:8c:56:38:c6:0a:1e:a8:af:f5:b9:42:02:6b:
77:e0:b1:1c:4a:88:e6:6f:b6:17:d3:59:41:d7:a0:62:86:59:
29:79:26:76:34:d1:16:2d:75:05:cb:b2:99:bf:ca:c6:68:1b:
b6:a9:b0:f4:43:2e:df:e3:7f:3c:b3:72:1a:99:fa:5d:94:a1:
eb:57:9c:9a:2c:87:d6:40:32:c9:ff:a6:54:b8:91:87:fd:90:
55:ef:12:3e:1e:2e:cf:c5:ea:c3:4c:09:62:4f:88:00:a0:7f:
cd:67:83:bc:27:e1:74:2c:18:4e:3f:12:1d:ef:29:0f:e3:27:
00:ce:14:eb:f0:01:f0:36:25:a2:33:a8:c6:2f:31:18:22:30:
cf:ca:97:43:ed:84:75:53:ab:b7:6c:75:f7:2f:55:5c:2e:82:
0a:be:91:59:bf:c9:06:ef:bb:b4:a2:71:9e:03:b1:25:8e:29:
7a:30:88:66:b4:f2:16:6e:df:ad:78:ff:d3:b2:9c:29:48:e3:
be:87:5c:fc:20:2b:df:da:ca:30:58:c3:04:c9:63:72:48:8c:
0a:5f:97:71
Appendix B. Example Certificate Revocation List Appendix B. Example Certificate Revocation List
The following is an example Certificate Revocation List. The following is an example Certificate Revocation List.
CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl CRL Name: q66IrWSGuBE7jqx8PAUHAlHCqRw.crl
Data: Data:
Version: 2 Version: 2
Signature Algorithm: Signature Algorithm:
Hash: SHA256, Encryption: RSA Hash: SHA256, Encryption: RSA
Issuer: CN=Demo Production APNIC CA - Not for real use, Issuer: CN=Demo Production APNIC CA - Not for real use,
E=ca@apnic.net E=ca@apnic.net
This Update: Thu Jul 27 06:30:34 2006 GMT This Update: Thu Jul 27 06:30:34 2006 GMT
Next Update: Fri Jul 28 06:30:34 2006 GMT Next Update: Fri Jul 28 06:30:34 2006 GMT
 End of changes. 49 change blocks. 
203 lines changed or deleted 247 lines changed or added

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