draft-ietf-sidr-keyroll-00.txt   draft-ietf-sidr-keyroll-01.txt 
SIDR G. Huston SIDR G. Huston
Internet-Draft G. Michaelson Internet-Draft G. Michaelson
Intended status: BCP APNIC Intended status: BCP APNIC
Expires: April 3, 2011 S. Kent Expires: April 4, 2011 S. Kent
BBN BBN
September 30, 2010 October 1, 2010
CA Key Rollover in the RPKI CA Key Rollover in the RPKI
draft-ietf-sidr-keyroll-00.txt draft-ietf-sidr-keyroll-01.txt
Abstract Abstract
This document describes an algorithm to allow an entity who This document describes an algorithm to allow an entity who
undertakes the role of a Certification Authority in the Resource undertakes the role of a Certification Authority in the Resource
Public Key Infrastructure to perform a rollover of its key pair. Public Key Infrastructure to perform a rollover of its key pair.
This document also notes the requirements placed on Relying Parties This document also notes the requirements placed on Relying Parties
who maintain a local cache of the objects that have been published in who maintain a local cache of the objects that have been published in
the distributed Resource Public Key Infrastructure repository the distributed Resource Public Key Infrastructure repository
publication structure. publication structure.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 3, 2011. This Internet-Draft will expire on April 4, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Concepts . . . . . . . . . . . . . . . . . 3
2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . . 3 2. CA Key Rollover Procedure . . . . . . . . . . . . . . . . . . . 3
3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 6 3. Relying Party Requirements . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 4. Reissuing Certificates and RPKI Signed Objects . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . . 7
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. RPKI Signed Objects . . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
This document describes an algorithm to allow an entity undertaking This document describes an algorithm to by employed by a
the role of a Certification Authority (CA) in the Resource Public Key Certification Authority (CA) in the Resource Public Key
Infrastucture (RPKI) [ID.ietf-sidr-arch] to perform a rollover of its Infrastructure (RPKI) [ID.ietf-sidr-arch] to perform a rollover of
key pair. its key pair.
The intent of this document is to define a conservative procedure for This document defines a conservative procedure for such entities to
such entities to follow when performing a key rollover so that follow when performing a key rollover, so that Relying Parties are in
Relying Parties are in a position to be able to validate all a position to be able to validate all authentic objects in the RPKI
authentic objects in the RPKI using the validation procedure using the validation procedure described in [ID.ietf-sidr-arch] at
described in [ID.ietf-sidr-res-certs] at all times. all times.
1.1. Terminology and Concepts 1.1. Terminology and Concepts
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509 and Certificate Revocation List (CRL) Profile" [RFC5280], "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779], and the Extensions for IP Addresses and AS Identifiers" [RFC3779], the
profile for RPKI Certificates [ID.ietf-sidr-res-certs] . profile for RPKI Certificates [ID.ietf-sidr-res-certs], and the RPKI
repository structure [ID.ietf-sidr-repos-struct] .
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. CA Key Rollover Procedure 2. CA Key Rollover Procedure
A CA instance is associated with a single key pair A certification Authority (CA) in the RPKI is an entity that issues
certificates and CRLs. Over time, there will be many instances of a
CA. A CA instance is associated with a single key pair
([ID.ietf-sidr-res-certs]). The implication in the context of key ([ID.ietf-sidr-res-certs]). The implication in the context of key
rollover is that, strictly speaking, a CA does not perform a key rollover is that, strictly speaking, a CA does not perform a key
rollover per se. In order to perform the equivalent of a key rollover per se. In order to perform the equivalent of a key
rollover, the entity who undertakes the role of a CA needs to rollover, the CA creates a new instance of itself, with a new key
instantiate a new instance of a CA, with the new key pair, and then pair, and then substitutes this new CA instance into the RPKI
substitute this new CA into the RPKI hierarchy in place of the old hierarchy in place of the old CA instance.
CA.
There are some considerations regarding this procedure that should be There are several considerations regarding this procedure that MUST
followed by an entity performing a key rollover operation. The be followed by a CA performing a key rollover operation. The
critical consideration is that the RPKI has potential application in critical consideration is that the RPKI has potential application in
the area of control of routing integrity [ID.ietf-sidr-arch], and key the area of control of routing integrity [ID.ietf-sidr-arch], , and
rollover should not cause any transient hiatus where a Relying Party key rollover should not cause any transient hiatus where a Relying
is led to incorrect conclusions regarding the authenticity of Party (RP) is led to incorrect conclusions regarding the authenticity
attestations and authorities made in the context of the RPKI. A CA of attestations made in the context of the RPKI. A CA cannot assume
should not assume that Relying Parties will universally use one form that all RPs will perform path validation and path discovery in the
of construction of a potential validation path over any other, and same fashion, and therefore the key rollover procedure MUST preserve
therefore the key rollover procedure should endeavour at all times to the integrity of the CRLDP, SIA and AIA pointers in RPKI
preserve the integrity of the SIA and AIA pointers in RPKI
certificates. certificates.
In the procedure described here, the entity creates a "new" CA In the procedure described here, the CA creates a new CA instance,
instance, and has the associated new public key published in the form and has the associated new public key published in the form of a new
af a "new" CA certificate. While the "current" and "new" CA CA certificate. While the current and new CA instances share a
instances share a single repository publication point, each CA has single repository publication point, each CA has its own CRL and its
its own CRL, and its own manifest. Initially, the "new" CA publishes own manifest. Initially, the new CA publishes an empty CRL and a
an empty CRL and a manifest that contains a single entry for the CRL. manifest that contains a single entry for the CRL. The "current" CA
The "current" CA also is also maintains its published CRL and manifest at this Repository
publication point.
The entity should then wait for a period of time to allow Relying The CA performing key rollover waits for a period of time to afford
Parties to discover and retrieve this "new" CA certificate and store every RP an opportunity to discover and retrieve this new CA
it in their local RPKI Repository cache instances (this period of certificate, and store it in its local RPKI Repository cache
time is termed the "staging period"). During this period, the entity instance. This period of time is termed the "staging period".
will have a "new" CA instance, with no subordinate products, and an During this period, the CA will have a new CA instance, with no
"current" CA instance which has issued all subordinate products. At subordinate products, and a current CA instance that has issued all
the expiration of the staging period the "new" CA instance can re- subordinate products. At the expiration of the staging period the
issue all subordinate products of the previous CA instance, new CA instance MUST replace all (valid) subordinate products of the
overwriting the old subordinate products in the CA's repository current CA instance, overwriting the current subordinate products in
publication point. When this is complete the "current" CA instance the CA's repository publication point. When this process is complete
can be retired, and the "new" CA instance can be re-termed the the current CA instance is retired, and the new CA instance becomes
"current" CA. the current CA.
During the transition of the CA instances it is necessary for the During the transition of the current and new CA instances it is
"new" CA instance to re-issue all subordinate products of the necessary for the new CA instance to re-issue all subordinate
"current" CA. The procedure described here specifies that, with the products of the current CA. The procedure described here requires
exception of manifests and CRLs, the re-issued subordinate products that, with the exception of manifests and CRLs, the re-issued
be published using the same repository publication point object subordinate products be published using the same repository
names, effectively overwriting the old subordinate objects with these publication point object names, effectively overwriting the old
re-issued subordinate objects. The intent of this overwriting objects with these re-issued objects. The intent of this overwriting
operation is to ensure that the AIA pointers of indirect subordinate operation is to ensure that the AIA pointers of subordinate products
products at lower levels in the PKI hierarchy remain correct, and at lower tiers in the RPKI hierarchy remain correct, and that CA key
that CA rollover does not require any associated actions by any rollover does not require any associated actions by any subordinate
subordinate CA. CA.
There are four CA states described here: There are three CA states described here:
CURRENT: CURRENT:
The CA is the active CA used to process certificate issuance and The CURRENT CA is the active CA instance used to accept and
revocation requests from subordinate entities. process certificate issuance and revocation requests The starting
point for this algorithm is that the key of the CURRENT CA is to
be rolled over.
NEW: NEW:
The CA is in the process of being created. The CA is unable to The NEW CA is the CA instance that is being created. The NEW CA
process certificate issuance and revocation requests from is not active, and thus does not accept nor process certificate
subordinate entities. The CA may issue a CRL and an EE issuance and revocation requests. The NEW CA SHOULD issue a CRL
certificate in association with its Manifest, but has no other and an EE certificate in association with its manifest to provide
subordinate products. a trivial, complete, consistent instance of a CA.
PENDING:
The CA is in the process of being set up. The CA is able to able
to issue certificates that were previously issued with the old
key, but is not able to process new certificate issuance and
revocation requests from subordinate entities.
OLD: OLD:
The CA is in the process of being removed. The CA is able to The CA instance is in the process of being removed. An OLD CA
unable to process any certificate issuance and revocation requests instance is unable to process any certificate issuance and
from subordinate entities. The CA will continue to issue revocation requests. An OLD CA instance will continue to issue
regularly scheduled CRLs and be permitted to issue an EE regularly scheduled CRLs and issue an EE certificate as part of
certificate as part of the process of updating its manifest to the process of updating its manifest to reflect the updated CRL.
reflect the updated CRL.
To perform a key rollover operation the entity MUST perform the To perform a key rollover operation the CA MUST perform the following
following steps in the order given here. Unless specified otherwise steps in the order given here. Unless specified otherwise each step
each step SHOULD be performed without any intervening delay. The SHOULD be performed without any intervening delay. The process MUST
process MUST be run through to completion. be run through to completion.
1. Generate a NEW key pair. 1. Generate a new key pair for use by the NEW CA. Because the
goal of this algorithm is key rollover, the key pair generated
in this step MUST be different from the pair in use by the
CURRENT CA.
2. Generate a certificate request with the NEW key pair and pass 2. Generate a certificate request with this key pair and pass the
the request to the entity's immediate superior CA as the CA request to the CA that issued the CURRENT CA certificate.
certificate Issuer. This request MUST include the same SIA extension that is
present in the CURRENT CA certificate. This request, when
satisfied, will result in the publication of the NEW CA
certificate. This (NEW) CA certificate will contain an
Subject Name selected by the issuer, which MUST be distinct
from the Subject Name used in the CURRENT CA certificate. The
CPS for the issuer of the NEW CA certificate will indicate the
time frame within which a certificate request is expected to
be processed.
3. Request the entity's Issuer to generate and publish a NEW CA 3. Publish the NEW CA's CRL and manifest.
certificate, with an issuer-selected Subject Name that is
distinct from the Subject Name used in the CURRENT CA
certificate for this entity.
4. Wait for a "Staging Period" following the completion of the The steps involved here are:
NEW CA certificate request. This "Staging Period is selected
by the entity, and MUST be no less than 24 hours.
5. Upon expiration of the Staging Period, suspend the processing - Wait for the issuer of the NEW CA to publish the NEW CA
of subordinate certificate issuance requests and revocation certificate.
requests. Mark the CURRENT CA as OLD and the NEW CA as
PENDING. Halt the operation of the OLD CA for all operations
except the further issuance of subsequent CRLs and EE
certificates for Manifests.
6. Use the PENDING CA to generate new certificates for all - As quickly as possible following the publication of the
existing subordinate CA and EE certificates, and publish NEW CA certificate, use the key pair associated with the
those products in the same repository publication point and NEW CA to generate an initial, empty CRL, and publish
with the same repository publication point name as the this CRL in the NEW CA's repository publication point.
previous OLD subordinate CA and EE certificates. The keys in
these reissued certificates must not change.
7. Excluding manifests, where the signing structure uses a It is RECOMMENDED that the CRL for the NEW CA have a
packaging format that includes the EE certificate within the nextUpdate value that will cause the CRL to be replaced
signed data, signed objects that included OLD CA-issed EE at the end of the Staging Period (see in Step 4 below).
certificates in their signed data will need to be re-signed
using an EE certificate issued by the PENDING CA. In the
case where the OLD CA-issued EE certificate is a "single use"
EE certificate and the associated private key has been
previously destroyed, this will entail the generation of a
new key pair, the issuing of an EE certificate by the PENDING
CA, and the signing of the data by the newly generated
private key. In the case of a "multi-use" EE certificate,
the EE certificate should be issued using the PENDING CA.
The object, together with the issued EE certificate, should
be signed with the associated private key, and published in
the same repository publication point, using the same
repository publication point name, as the previously signed
object that it replaces (i.e. overwrite the old signed
object).
8. Use the OLD CA to issue a manifest that lists only the OLD - Generate a new key pair, and generate an associated EE
CA's CRL, and use the PENDING CA to issue a manifest that certificate request with an AIA value of the NEW CA's
lists all subordinate products that were issued by the repository publication point. Pass this EE certificate
PENDING CA. request to the NEW CA, and use the returned (single-use)
EE certificate as the NEW CA's manifest EE certificate.
9. Mark the PENDING CA as CURRENT and resume processing - Generate a manifest containing the new CA's CRL as the
subordinate certificate issuance requests. only entry, and sign it with the private key associated
with the manifest EE certificate. Publish the manifest
at the NEW CA's repository publication point.
10. Generate a certificate revocation request for the OLD CA - Destroy the private key associated with the manifest EE
certificate and pass it to the entity's Issuer. certificate.
11. Wait for completion of the OLD CA certificate revocation 4. The NEW CA enters a Staging Period. This duration of the
request, then remove the OLD CA's CRL and Manifest and Staging Period is determined by the CA, but it MUST be no less
destroy the OLD private key. than 24 hours. The Staging Period is intended to afford an
opportunity for all RPs to download the NEW CA certificate,
prior to publication of certificates, CRLs, and RPKI signed
objects under the NEW CA. During the Staging Period, the NEW
CA SHOULD reissue, but not publish, all of the products that
were issued under the CURRENT CA. This includes all CA
certificates, EE certificates, and RPKI signed objects.
Section 4 describes how each reissued product relates to the
product that it replaces. During the Staging Period, the
CURRENT CA SHOULD continue to accept and process certificate
issuance requests and MUST continue to accept and process
certificate revocation requests. If any certificates are
issued by the CURRENT CA during the staging period, they MUST
be re-issued under the NEW CA during the period. Any
certificates that are revoked under the CURRENT CA MUST NOT be
re-issued under the NEW CA.
5. Upon expiration of the Staging Period, the NEW CA MUST publish
the signed products that have been re-issued under the NEW CA,
replacing the corresponding products issued under the CURRENT
CA at the NEW CA's repository publication point. This
replacement is implied by the file naming requirements imposed
by [ID.ietf-sidr-repos-struct] for these signed products. The
trivial manifest for the NEW CA (which contained only one
entry, for the NEW CA's CRL) is replaced by a manifest listing
all of these reissued, signed products. At this point the
CURENT CA becomes the OLD CA, and the NEW CA becomes the
CURRENT CA. Use the OLD CA to issue a manifest that lists
only the OLD CA's CRL. It is anticipated that this step is
very brief, perhaps a few minutes in duration, because the CA
has reissued all of the signed products during the Staging
Period. Nonetheless, it is desirable that the activities
performed in this step be viewed as atomic by RPs.
6. Generate a certificate revocation request for the OLD CA
certificate and submit it to the issuer of that certificate.
When the OLD CA certificate is revoked, the CRL for the OLD CA
is removed from the repository, along with the manifest for
the OLD CA. The private key for the OLD CA is destroyed.
3. Relying Party Requirements 3. Relying Party Requirements
This procedure defines a "Staging Period" for CAs performing a key This procedure defines a Staging Period for CAs performing a key
rollover operation, which is defined as a period no shorter than 24 rollover operation. This period is defined as a period no shorter
than 24 hours.
RPs who maintain a local cache of the distributed RPKI repository
MUST perform a local cache synchronisation operation against the
distributed RPKI repository at regular intervals of no longer than 24
hours. hours.
Relying Parties who maintain a local cache of the distributed RPKI 4. Reissuing Certificates and RPKI Signed Objects
repository MUST perform a local cache synchronisation operation
against the distributed RPKI repository at regular intervals of no
longer than 24 hours.
4. Security Considerations This section provides rules a CA MUST use when it reissues
certificates and RPKI signed objects as part of the key rollover
process. Note that CRLs and manifests are not reissued, per se.
They are generated for each CA instance. A manifest catalogues the
contents of a publication point relative to a CA instance. A CRL
lists revoked certificates, relative to a CA instance. Key rollover
processing for CRLs and manifests is described above, in Section 3.
4.1. CA Certificates
When a CA, as part of the key rollover process, reissues a CA
certificate, it copies all of the field and extension values from the
old certificate into the new certificate. The only exceptions to
this rule is that the certificate serial number MUST change, and the
notBefore value MAY be set to the current date and time.
4.2. RPKI Signed Objects
An RPKI signed object is a CMS signed-data object, containing an EE
certificate and a payload (content). When a key rollover occurs, the
EE certificate for the RPKI signed object MUST be reissued, under the
key of the NEW CA. A CA may choose to treat this EE certificate the
same way that it deals with CA certificates, i.e., to copy over all
fields and extensions, and change only the serial number and the
notBefore date. If the CA adopts this approach, then the new EE
certificate is inserted into the CMS wrapper, but the signed context
remains the same. (If the signing time or binary signing time values
in the CMS wrapper are non-null, they MAY be updated to reflect the
current time.) Alternatively, the CA MAY elect to generate a new key
pair for this EE certificate. If it does so, the object content MUST
be resigned under the private key corresponding to the EE
certificate. In this case the EE certificate MUST contain a new
public key and a new notBefore value, it MAY contain a new notAfter
value, but all other field and extension values remain constant. (If
the signing time or binary signing time values in the CMS wrapper are
non-null, they MAY be updated to reflect the current time.)
5. Security Considerations
[To be added] [To be added]
5. IANA Considerations 6. 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.]
6. Acknowledgements 7. Acknowledgements
The authors would like to acknowledge the review comments of Tim The authors would like to acknowledge the review comments of Tim
Bruijnzeels in preparing this document. Bruijnzeels in preparing this document.
7. References 8. References
7.1. Normative References 8.1. Normative References
[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, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
7.2. Informative References 8.2. Informative References
[ID.ietf-sidr-arch] [ID.ietf-sidr-arch]
Lepinski, M. and S. Kent, "An Infrastructure to Support Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", draft-ietf-sidr-arch-11 (work in Secure Internet Routing", draft-ietf-sidr-arch-11 (work in
progress), September 2010. progress), September 2010.
[ID.ietf-sidr-repos-struct]
Huston, G., Loomans, R., and G. Michaleson, "A Profile for
Resource Certificate Repository Structure", Internet
Draft draft-ietf-sidr-repos-struct-04.txt, May 2010.
[ID.ietf-sidr-res-certs] [ID.ietf-sidr-res-certs]
Huston, G., Michaleson, G., and R. Loomans, "A Profile for Huston, G., Michaleson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Internet X.509 PKIX Resource Certificates", Internet
Draft draft-ietf-sidr-res-certs-18.txt, May 2010. Draft draft-ietf-sidr-res-certs-18.txt, May 2010.
Authors' Addresses Authors' Addresses
Geoff Huston Geoff Huston
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
 End of changes. 40 change blocks. 
156 lines changed or deleted 226 lines changed or added

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