< draft-ietf-sidr-res-certs-16.txt   draft-ietf-sidr-res-certs-17.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: August 30, 2009 APNIC Expires: March 19, 2010 APNIC
February 26, 2009 September 15, 2009
A Profile for X.509 PKIX Resource Certificates A Profile for X.509 PKIX Resource Certificates
draft-ietf-sidr-res-certs-16 draft-ietf-sidr-res-certs-17
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 August 30, 2009. This Internet-Draft will expire on March 19, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
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 14 skipping to change at page 3, line 13
5.1.1. PKCS#10 Resource Certificate Request Template 5.1.1. PKCS#10 Resource Certificate Request Template
Fields . . . . . . . . . . . . . . . . . . . . . . . . 17 Fields . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 18 5.2. CRMF Profile . . . . . . . . . . . . . . . . . . . . . . . 18
5.2.1. CRMF Resource Certificate Request Template Fields . . 18 5.2.1. CRMF Resource Certificate Request Template Fields . . 18
5.2.2. Resource Certificate Request Control Fields . . . . . 19 5.2.2. Resource Certificate Request Control Fields . . . . . 19
5.3. Certificate Extension Attributes in Certificate 5.3. Certificate Extension Attributes in Certificate
Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19 Requests . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Resource Certificate Validation . . . . . . . . . . . . . . . 22 6. Resource Certificate Validation . . . . . . . . . . . . . . . 22
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
7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Design Notes . . . . . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29
11.2. Informative References . . . . . . . . . . . . . . . . . . 30 11.2. Informative References . . . . . . . . . . . . . . . . . . 30
Appendix A. Example Resource Certificate . . . . . . . . . . . . 30 Appendix A. Example Resource Certificate . . . . . . . . . . . . 30
Appendix B. Example Certificate Revocation List . . . . . . . . . 32 Appendix B. Example Certificate Revocation List . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
skipping to change at page 6, line 49 skipping to change at page 6, line 49
field is 2). field is 2).
3.2. Serial number 3.2. Serial number
The serial number value is a positive integer that is unique per The serial number value is a positive integer that is unique per
Issuer. Issuer.
3.3. Signature Algorithm 3.3. Signature Algorithm
This field describes the algorithm used to compute the signature on This field describes the algorithm used to compute the signature on
this certificate. This profile specifies a default of SHA-256 with this certificate. The algorithm used in this profile is specified in
RSA (sha256WithRSAEncryption), and allows for the use of SHA-384 or [ID.sidr-rpki-algs].
SHA-512. Accordingly, the value for this field MUST be one of the
OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 } [RFC4055].
3.4. Issuer 3.4. Issuer
This field identifies the entity that has signed and issued the This field identifies the entity that has signed and issued the
certificate. The value of this field is a valid X.501 distinguished certificate. The value of this field is a valid X.501 distinguished
name. Conventions are imposed on Issuer names used in resource name. Conventions are imposed on Issuer names used in resource
certificates, as described in [ID.sidr-arch]. certificates, as described in [ID.sidr-arch].
If the certificate is a subordinate certificate issued by virtue of If the certificate is a subordinate certificate issued by virtue of
the "cA" bit set in the immediate superior certificate, then the the "cA" bit set in the immediate superior certificate, then the
skipping to change at page 8, line 32 skipping to change at page 8, line 32
While a CA is typically advised against issuing a certificate with a While a CA is typically advised against issuing a certificate with a
validity interval that exceeds the validity interval of the CA's validity interval that exceeds the validity interval of the CA's
certificate that will be used to validate the issued certificate, in certificate that will be used to validate the issued certificate, in
the context of this profile, it is anticipated that a CA may have the context of this profile, it is anticipated that a CA may have
valid grounds to issue a certificate with a validity interval that valid grounds to issue a certificate with a validity interval that
exceeds the validity interval of its certificate. exceeds the validity interval of its certificate.
3.8. Subject Public Key Info 3.8. Subject Public Key Info
This field specifies the subject's public key and the algorithm with This field specifies the subject's public key and the algorithm with
which the key is used. The public key algorithm MUST be RSA, and, which the key is used. The algorithm used in this profile is
accordingly, the OID for the public key algorithm is specified in [ID.sidr-rpki-algs].
1.2.840.113549.1.1.1. The key size MUST be a minimum size of 2048
bits.
It is noted that larger key sizes are computationally expensive for It is noted that larger key sizes are computationally expensive for
both the CA and relying parties, indicating that care should be taken both the CA and relying parties, indicating that care should be taken
when deciding to use larger than the minimum key size noted above. when deciding to use larger than the minimum key size noted in
[ID.sidr-rpki-algs]..
3.9. Resource Certificate Version 3 Extension Fields 3.9. Resource Certificate Version 3 Extension Fields
As noted in Section 4.2 of [RFC5280], each extension in a certificate As noted in Section 4.2 of [RFC5280], each extension in a certificate
is designated as either critical or non-critical. A certificate- is designated as either critical or non-critical. A certificate-
using system MUST reject the certificate if it encounters a critical using system MUST reject the certificate if it encounters a critical
extension it does not recognize; however, a non-critical extension extension it does not recognize; however, a non-critical extension
MAY be ignored if it is not recognized [RFC5280]. MAY be ignored if it is not recognized [RFC5280].
The following X.509 V3 extensions MUST be present in a conforming The following X.509 V3 extensions MUST be present in a conforming
skipping to change at page 15, line 27 skipping to change at page 15, line 27
4.4. Next Update 4.4. Next Update
This is the date and time by which the next CRL SHOULD be issued. This is the date and time by which the next CRL SHOULD be issued.
The value of this field MUST be encoded as UTCTime for dates through The value of this field MUST be encoded as UTCTime for dates through
the year 2049, and MUST be encoded as GeneralizedTime for dates in the year 2049, and MUST be encoded as GeneralizedTime for dates in
the year 2050 or later. the year 2050 or later.
4.5. Signature 4.5. Signature
This field contains the algorithm used to sign this CRL. This This field contains the algorithm used to sign this CRL. The
profile specifies a default of SHA-256 with RSA algorithm used in this profile is specified in [ID.sidr-rpki-algs].
(sha256WithRSAEncryption), and allows for the use of SHA-384 or SHA-
512.
It is noted that larger key sizes are computationally expensive for It is noted that larger key sizes are computationally expensive for
both the CRL Issuer and relying parties, indicating that care should both the CRL Issuer and relying parties, indicating that care should
be taken when deciding to use larger than the default key size. be taken when deciding to use larger than the default key size
specified in [ID.sidr-rpki-algs].
4.6. Revoked Certificate List 4.6. Revoked Certificate List
When there are no revoked certificates, then the revoked certificate When there are no revoked certificates, then the revoked certificate
list MUST be absent. list MUST be absent.
For each revoked resource certificate only the following fields MUST For each revoked resource certificate only the following fields MUST
be present. No CRL entry extensions are supported in this profile, be present. No CRL entry extensions are supported in this profile,
and CRL entry extensions MUST NOT be present in a CRL. and CRL entry extensions MUST NOT be present in a CRL.
skipping to change at page 17, line 22 skipping to change at page 17, line 21
Version Version
This field is mandatory and MUST have the value 0. This field is mandatory and MUST have the value 0.
Subject Subject
This field is optional. If present, the value of this field This field is optional. If present, the value of this field
SHOULD be empty, in which case the issuer MUST generate a SHOULD be empty, in which case the issuer MUST generate a
subject name that is unique in the context of certificates subject name that is unique in the context of certificates
issued by this issuer. If the value of this field is non- issued by this issuer. If the value of this field is non-
empty, then the CA MAY consider the value of this field as the empty, then the CA MAY consider the value of this field as the
subject's suggested subject name, but the CA is NOT bound to subject's suggested subject name, but the CA is NOT bound to
honor this suggestion, as the subject name MUST be unique per honour this suggestion, as the subject name MUST be unique per
subordinate CA and EE in certificates issued by this issuer. subordinate CA and EE in certificates issued by this issuer.
SubjectPublicKeyInfo SubjectPublicKeyInfo
This field specifies the subject's public key and the algorithm This field specifies the subject's public key and the algorithm
with which the key is used. The public key algorithm MUST be with which the key is used. The algorithm used in this profile
RSA, and the OID for the algorithm is 1.2.840.113549.1.1.1. is specified in [ID.sidr-rpki-algs].
This field also includes a bit-string representation of the
entity's public key. For the RSA public-key algorithm the bit
string contains the DER encoding of a value of PKCS #1 type
RSAPublicKey.
Attributes Attributes
[RFC2986] defines the attributes field as key-value pairs where [RFC2986] defines the attributes field as key-value pairs where
the key is an OID and the value's structure depends on the key. the key is an OID and the value's structure depends on the key.
The only attribute used in this profile is the ExtensionRequest The only attribute used in this profile is the ExtensionRequest
attribute as defined in [RFC2985]. This attribute contains attribute as defined in [RFC2985]. This attribute contains
X509v3 Certificate Extensions. The profile for extensions in X509v3 Certificate Extensions. The profile for extensions in
certificate requests is specified in Section 5.3. certificate requests is specified in Section 5.3.
This profile applies the following additional constraints to fields This profile applies the following additional constraints to fields
that MAY appear in a CertificationRequest Object: that MAY appear in a CertificationRequest Object:
signatureAlgorithm signatureAlgorithm
This profile specifies a default of SHA-256 with RSA The algorithm used in this profile is specified in
(sha256WithRSAEncryption), and allows for the use of SHA-384 or [ID.sidr-rpki-algs].
SHA-512. Accordingly, the value for this field MUST be one of
the OID values { pkcs-1 11 }, { pkcs-1 12 } or { pkcs-1 13 }
[RFC4055].
It is noted that larger key sizes are computationally expensive It is noted that larger key sizes are computationally expensive
for both the CA and relying parties, indicating that care for both the CA and relying parties, indicating that care
should be taken when deciding to use larger than the default should be taken when deciding to use larger than the default
key size. key size specified in [ID.sidr-rpki-algs].
5.2. CRMF Profile 5.2. CRMF Profile
This profile refines the Certificate Request Message Format (CRMF) This profile refines the Certificate Request Message Format (CRMF)
specification in [RFC4211], as it relates to Resource Certificates. specification in [RFC4211], as it relates to Resource Certificates.
A Certificate Request Message object, formatted according to the A Certificate Request Message object, formatted according to the
CRMF, is passed to a CA as the initial step in issuing a certificate. CRMF, is passed to a CA as the initial step in issuing a certificate.
This request MAY be conveyed to the CA via a Registration Authority This request MAY be conveyed to the CA via a Registration Authority
(RA), acting under the direction of a subject. (RA), acting under the direction of a subject.
skipping to change at page 19, line 22 skipping to change at page 19, line 5
specified, then the CA MAY override the requested values with specified, then the CA MAY override the requested values with
dates as determined by the CA. dates as determined by the CA.
Subject Subject
This field is optional. If present, the value of this field This field is optional. If present, the value of this field
SHOULD be empty, in which case the issuer MUST generate a SHOULD be empty, in which case the issuer MUST generate a
subject name that is unique in the context of certificates subject name that is unique in the context of certificates
issued by this issuer. If the value of this field is non- issued by this issuer. If the value of this field is non-
empty, then the CA MAY consider the value of this field as the empty, then the CA MAY consider the value of this field as the
subject's suggested subject name, but the CA is NOT bound to subject's suggested subject name, but the CA is NOT bound to
honor this suggestion, as the subject name MUST be unique per honour this suggestion, as the subject name MUST be unique per
issuer in certificates issued by this issuer. issuer in certificates issued by this issuer.
PublicKey PublicKey
This field MUST be present. This field MUST be present.
extensions extensions
This attribute contains X509v3 Certificate Extensions. The This attribute contains X509v3 Certificate Extensions. The
profile for extensions in certificate requests is specified in profile for extensions in certificate requests is specified in
Section 5.3. Section 5.3.
skipping to change at page 20, line 14 skipping to change at page 19, line 41
BasicConstraints BasicConstraints
If this is omitted then the CA will issue an end entity If this is omitted then the CA will issue an end entity
certificate with the BasicConstraints extension not present in certificate with the BasicConstraints extension not present in
the issued certificate. the issued certificate.
The Path Length Constraint is not supported in this Resource The Path Length Constraint is not supported in this Resource
Certificate Profile, and this field MUST be omitted in this Certificate Profile, and this field MUST be omitted in this
profile. profile.
The CA MAY honor the SubjectType CA bit set to on. If this bit The CA MAY honour the SubjectType CA bit set to on. If this
is set, then it indicates that the Subject is allowed to issue bit is set, then it indicates that the Subject is allowed to
resource certificates within this overall framework. issue resource certificates within this overall framework.
The CA MUST honor the SubjectType CA bit set to off (End Entity The CA MUST honour the SubjectType CA bit set to off (End
certificate request), in which case the corresponding end Entity certificate request), in which case the corresponding
entity certificate will not contain a BasicConstraints end entity certificate will not contain a BasicConstraints
extension. extension.
SubjectKeyIdentifier SubjectKeyIdentifier
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.
AuthorityKeyIdentifier AuthorityKeyIdentifier
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.
KeyUsage KeyUsage
The CA MAY honor KeyUsage extensions of keyCertSign and cRLSign The CA MAY honour KeyUsage extensions of keyCertSign and
if present, as long as this is consistent with the cRLSign if present, as long as this is consistent with the
BasicConstraints SubjectType sub field, when specified. BasicConstraints SubjectType sub field, when specified.
ExtendedKeyUsage ExtendedKeyUsage
The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and The CA MAY honour ExtendedKeyUsage extensions of keyCertSign
cRLSign if present, as long as this is consistent with the and cRLSign if present, as long as this is consistent with the
BasicConstraints SubjectType sub field, when specified. BasicConstraints SubjectType sub field, when specified.
SubjectInformationAccess SubjectInformationAccess
This field MUST be present when the subject is a CA, and the This field MUST be present when the subject is a CA, and the
field value SHOULD be honored by the CA. If the CA is not able field value SHOULD be honoured by the CA. If the CA is not
to honor the requested field value, then the CA MUST reject the able to honour the requested field value, then the CA MUST
Certificate Request. reject the Certificate Request.
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.
skipping to change at page 21, line 28 skipping to change at page 21, line 12
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 accessMethod, 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 honoured by the CA. If the
is not able to honor the requested field value, then the CA CA is not able to honour 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 honour 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 honour 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 certificate MUST include in the SIA of the request an
accessMethod 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 accessMethod OID of id-ad- include in the SIA of the request an accessMethod OID of id-ad-
rpkiManifest, where the associated access location refers to rpkiManifest, where the associated access location refers to
the publication point of the manifest object describing all the publication point of the manifest object describing all
objects that are verified using this EE certificate. objects that are verified using this EE certificate.
skipping to change at page 29, line 25 skipping to change at page 29, line 20
the text. The authors also acknowledge the contributions of Sandy the text. The authors also acknowledge the contributions of Sandy
Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara Murphy, Robert Kisteleki, Randy Bush, Russ Housley, Ricardo Patara
and Rob Austein in the preparation and subsequent review of this and Rob Austein in the preparation and subsequent review of this
document. The document also reflects review comments received from document. The document also reflects review comments received from
Roque Gagliano, Sean Turner and David Cooper. Roque Gagliano, Sean Turner and David Cooper.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ID.sidr-rpki-algs]
Huston, G., "A Profile for Algorithms and Key Sizes for
use in the Resource Public Key Infrastructure", Work in
progress: Internet
Drafts draft-ietf-sidr-rpki-algs-00.txt, August 2009.
[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",
BCP 12, RFC 2050, November 1996. BCP 12, RFC 2050, November 1996.
[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.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
June 2005.
[RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure [RFC4211] Schaad, J., "Internet X.509 Public Key Infrastructure
Certificate Request Message Format (CRMF)", RFC 4211, Certificate Request Message Format (CRMF)", RFC 4211,
September 2005. September 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[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
 End of changes. 25 change blocks. 
62 lines changed or deleted 50 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/