draft-ietf-smime-escertid-01.txt   draft-ietf-smime-escertid-02.txt 
Network Working Group J. Schaad Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting Internet-Draft Soaring Hawk Consulting
Expires: October 19, 2006 April 17, 2006
Expires: October 3, 2006
ESS Update: Adding CertID Algorithm Agility ESS Update: Adding CertID Algorithm Agility
draft-ietf-smime-escertid-01.txt draft-ietf-smime-escertid-02.txt
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 33 skipping to change at page 1, line 34
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 October 19, 2006. This Internet-Draft will expire on October 3, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
In the original Enhanced Security Services for S/MIME draft, a In the original Enhanced Security Services for S/MIME draft, a
structure for cryptographically linking the certificate to be used in structure for cryptographically linking the certificate to be used in
validation with the signature was introduced, this structure was validation with the signature was introduced, this structure was
hardwired to use SHA-1. This document allows for the structure to hardwired to use SHA-1. This document allows for the structure to
have algorithm agility and defines new attributes to deal with the have algorithm agility and defines new attributes to deal with the
updating. updating.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Replace Section 5.4 Signing Certificate Attribute 2. Replace Section 5.4 'Signing Certificate Attribute
Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 Definitions' . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Insert new section 5.4.1 . . . . . . . . . . . . . . . . . . . 5 3. Insert new section 5.4.1 'Signing Certificate Attribute
4. Insert new section 5.4.1.1 . . . . . . . . . . . . . . . . . . 7 Definition Version 2' . . . . . . . . . . . . . . . . . . . . 5
5. Insert new section 5.4.2 . . . . . . . . . . . . . . . . . . . 9 4. Insert new section 5.4.1.1 'Certificate Identification
6. Renumber Section 5.4.1 Certificate Identification . . . . . . 11 Version 2' . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 5. Insert new section 5.4.2 ' Signing Certificate Attribute
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 Defintion Version 1 . . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Renumber Section 5.4.1 Certificate Identification Version 1 . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 18 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
In the original Enhanced Security Services (ESS) for S/MIME draft In the original Enhanced Security Services (ESS) for S/MIME draft
[ESS], a structure for cryptographically linking the certificate to [ESS], a structure for cryptographically linking the certificate to
be used in validation with the signature was defined. This be used in validation with the signature was defined. This
structure, called ESSCertID was hardwired to use a SHA-1 hash value. structure, called ESSCertID was hardwired to use a SHA-1 hash value.
The recent attacks on SHA-1 require that we change define a new The recent attacks on SHA-1 require that we change define a new
attribute which allows for the use of a different algorithm. This attribute which allows for the use of a different algorithm. This
document performs that task. document performs that task.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
attribute SigningCertificateV2 which uses the updated structure. attribute SigningCertificateV2 which uses the updated structure.
This document allows for the structure to have algorithm agility and This document allows for the structure to have algorithm agility and
defines new attributes to deal with the updating. defines new attributes to deal with the updating.
1.1. Notation 1.1. Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Replace Section 5.4 Signing Certificate Attribute Definitions 2. Replace Section 5.4 'Signing Certificate Attribute Definitions'
The signing certificate attribute is designed to prevent simple The signing certificate attribute is designed to prevent simple
substitution and re-issue attacks, and to allow for a restricted set substitution and re-issue attacks, and to allow for a restricted set
of authorization certificates to be used in verifying a signature. of authorization certificates to be used in verifying a signature.
Two different attributes exist for this due to a flaw in the original Two different attributes exist for this due to a flaw in the original
design. The only substantial difference between the two attributes design. The only substantial difference between the two attributes
is that SigningCertificateV2 allows for hash algorithm agility, while is that SigningCertificateV2 allows for hash algorithm agility, while
SigningCertificate forces the use of the SHA-1 hash algorithm. With SigningCertificate forces the use of the SHA-1 hash algorithm. With
the recent advances in the ability to create hash collisions for the recent advances in the ability to create hash collisions for
SHA-1 it is deemed wise to move forward sooner rather than later. SHA-1 it is deemed wise to move forward sooner rather than later.
When the SHA-1 hash function is used, the SigningCertificate When the SHA-1 hash function is used, the SigningCertificate
attribute MUST be used. The SigningCertificateV2 attribute MUST be attribute MUST be used. The SigningCertificateV2 attribute MUST be
used if any algorithm other than SHA-1 is used and SHOULD NOT be used used if any algorithm other than SHA-1 is used and SHOULD NOT be used
for SHA-1. Applications SHOULD recognize both attributes as long as for SHA-1. Applications SHOULD recognize both attributes as long as
they consider SHA-1 to be sufficiently descriminating. they consider SHA-1 able to distingusih between two different
certificates. (I.e. the possiblity of a collision is suffiently
low.)
3. Insert new section 5.4.1 3. Insert new section 5.4.1 'Signing Certificate Attribute Definition
Version 2'
5.4.1 Signing Certificate Attribute Definition 5.4.1 Signing Certificate Attribute Definition Version 2
The signing certificate attribute is designed to prevent the simple The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set substitution and re-issue attacks, and to allow for a restricted set
of authorization certificates to be used in verifying a signature. of authorization certificates to be used in verifying a signature.
The definition of SigningCertificateV2 is SigningCertificateV2 is identified by the OID:
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
The attribute has the ASN.1 definition:
SigningCertificateV2 ::= SEQUENCE { SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2, certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) XX } smime(16) id-aa(2) 47 }
certs contains the list of certificates that are to be used in certs contains the list of certificates that are to be used in
validating the message. The first certificate identified in the validating the message. The first certificate identified in the
sequence of certificate identifiers MUST be the certificate used sequence of certificate identifiers MUST be the certificate used
to verify the signature. The encoding of the ESSCertIDv2 for this to verify the signature. The encoding of the ESSCertIDv2 for this
certificate SHOULD include the issuerSerial field. If other certificate SHOULD include the issuerSerial field. If other
constraints ensure that issuerAndSerialNumber will be present in constraints ensure that issuerAndSerialNumber will be present in
the SignerInfo, the issuerSerial field MAY be omitted. The the SignerInfo, the issuerSerial field MAY be omitted. The
certificate identified is used during the signature verification certificate identified is used during the signature verification
process. If the hash of the certificate does not match the process. If the hash of the certificate does not match the
skipping to change at page 7, line 5 skipping to change at page 7, line 5
If present, the SigningCertificateV2 attribute MUST be a signed If present, the SigningCertificateV2 attribute MUST be a signed
attribute; it MUST NOT be an unsigned attribute. CMS defines attribute; it MUST NOT be an unsigned attribute. CMS defines
SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT
include multiple instances of the SigningCertificate attribute. CMS include multiple instances of the SigningCertificate attribute. CMS
defines the ASN.1 syntax for the signed attributes to include defines the ASN.1 syntax for the signed attributes to include
attrValues SET OF AttributeValue. A SigningCertificate attribute attrValues SET OF AttributeValue. A SigningCertificate attribute
MUST include only a single instance of AttributeValue. There MUST MUST include only a single instance of AttributeValue. There MUST
NOT be zero or multiple instances of AttributeValue present in the NOT be zero or multiple instances of AttributeValue present in the
attrValues SET OF AttributeValue. attrValues SET OF AttributeValue.
4. Insert new section 5.4.1.1 4. Insert new section 5.4.1.1 'Certificate Identification Version 2'
Insert the following text as a new section Insert the following text as a new section
5.4.1.1 Certificate Identification 5.4.1.1 Certificate Identification Version 2
The best way to identify certificates is an often-discussed issue. The best way to identify certificates is an often-discussed issue.
The ESSCertIDV2 structure supplies two different fields that are used The ESSCertIDV2 structure supplies two different fields that are used
for this purpose. for this purpose.
The hash of the entire certificate allows for a verifier to check The hash of the entire certificate allows for a verifier to check
that the certificate used in the verification process was the same as that the certificate used in the verification process was the same
the signer intended to be used. Hashes are convient in that they are certificate the signer intended. Hashes are convient in that they
frequently used by certificate stores as a method of indexing and are frequently used by certificate stores as a method of indexing and
retrieving certificates as well. The use of the hash is required by retrieving certificates as well. The use of the hash is required by
this structure since the detection of substitued certificates is this structure since the detection of substitued certificates is
based on the fact they would map to different hash values. based on the fact they would map to different hash values.
The issuer/serial number pair is the method of identification of The issuer/serial number pair is the method of identification of
certificates used in [PKIXCERT]. That document imposes a restriction certificates used in [PKIXCERT]. That document imposes a restriction
for certificates that the issuer DN must be present. The issuer/ for certificates that the issuer DN must be present. The issuer/
serial number pair would therefore normally be sufficient to identify serial number pair would therefore normally be sufficient to identify
the correct signing certificate. (This assumes the same issuer name the correct signing certificate. (This assumes the same issuer name
is not re-used from the set of trust anchors.) The issuer/serial is not re-used from the set of trust anchors.) The issuer/serial
number pair can be stored in the sid field of the SignerInfo object. number pair can be stored in the sid field of the SignerInfo object.
However the sid field is not covered by the signature. In the cases However the sid field is not covered by the signature. In the cases
where the issuer/serial number pair is not used in the sid or the where the issuer/serial number pair is not used in the sid or the
issuer/serial number need to be signed, they should be placed in the issuer/serial number pair needs to be signed, they SHOULD be placed
issuerSerial field of the ESSCertIDv2 structure. in the issuerSerial field of the ESSCertIDv2 structure.
Attribute certificates and additional public key certificates Attribute certificates and additional public key certificates
containing authorization information do not have an issuer/serial containing authorization information do not have an issuer/serial
number pair represented anywhere in a SignerInfo object. When an number pair represented anywhere in a SignerInfo object. When an
attribute certificate or an additional public key certificate is not attribute certificate or an additional public key certificate is not
included in the SignedData object, it becomes much more difficult to included in the SignedData object, it becomes much more difficult to
get the correct set of certificates based only on a hash of the get the correct set of certificates based only on a hash of the
certificate. For this reason, these certificates SHOULD be certificate. For this reason, these certificates SHOULD be
identified by the IssuerSerial object. identified by the IssuerSerial object.
skipping to change at page 8, line 20 skipping to change at page 8, line 20
Hash ::= OCTET STRING Hash ::= OCTET STRING
IssuerSerial ::= SEQUENCE { IssuerSerial ::= SEQUENCE {
issuer GeneralNames, issuer GeneralNames,
serialNumber CertificateSerialNumber serialNumber CertificateSerialNumber
} }
The fields of ESSCertIDv2 are defined as follows: The fields of ESSCertIDv2 are defined as follows:
certHash is computed over the entire DER encoded certificate
including the signature. The issuerSerial would normally be
present unless the value can be inferred from other information.
hashAlg contains the identifier of the algorithm used in computing hashAlg contains the identifier of the algorithm used in computing
certHash. certHash.
issuerSerial holds the identification of the certificate. certHash is computed over the entire DER encoded certificate
including the signature.
issuerSerial holds the identification of the certificate. The
issuerSerial would normally be present unless the value can be
inferred from other information.
The fields of IssuerSerial are defined as follows: The fields of IssuerSerial are defined as follows:
issuer contains the issuer name of the certificate. For non- issuer contains the issuer name of the certificate. For non-
attribute certificates, the issuer MUST contain only the issuer attribute certificates, the issuer MUST contain only the issuer
name from the certificate encoded in the directoryName choice of name from the certificate encoded in the directoryName choice of
GeneralNames. For attribute certificates, the issuer MUST contain GeneralNames. For attribute certificates, the issuer MUST contain
the issuer name field from the attribute certificate. the issuer name field from the attribute certificate.
serialNumber holds the serial number that uniquely identifies the serialNumber holds the serial number that uniquely identifies the
certificate. certificate.
5. Insert new section 5.4.2 5. Insert new section 5.4.2 ' Signing Certificate Attribute Defintion
Version 1
5.4.2 Signing Certificate Attribute Definition with SHA-1 5.4.2 Signing Certificate Attribute Definition Version 1
The signing certificate attribute is designed to prevent the simple The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set substitution and re-issue attacks, and to allow for a restricted set
of authorization certificates to be used in verifying a signature. of authorization certificates to be used in verifying a signature.
The definition of SigningCertificate is The definition of SigningCertificate is
SigningCertificate ::= SEQUENCE { SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID, certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
skipping to change at page 11, line 5 skipping to change at page 11, line 5
If present, the SigningCertificate attribute MUST be a signed If present, the SigningCertificate attribute MUST be a signed
attribute; it MUST NOT be an unsigned attribute. CMS defines attribute; it MUST NOT be an unsigned attribute. CMS defines
SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT
include multiple instances of the SigningCertificate attribute. CMS include multiple instances of the SigningCertificate attribute. CMS
defines the ASN.1 syntax for the signed attributes to include defines the ASN.1 syntax for the signed attributes to include
attrValues SET OF AttributeValue. A SigningCertificate attribute attrValues SET OF AttributeValue. A SigningCertificate attribute
MUST include only a single instance of AttributeValue. There MUST MUST include only a single instance of AttributeValue. There MUST
NOT be zero or multiple instances of AttributeValue present in the NOT be zero or multiple instances of AttributeValue present in the
attrValues SET OF AttributeValue. attrValues SET OF AttributeValue.
6. Renumber Section 5.4.1 Certificate Identification 6. Renumber Section 5.4.1 Certificate Identification Version 1
Change the number on this section from 5.4.1 to 5.4.2.1 Change the number on this section from 5.4.1 to 5.4.2.1
Change the title on this section to "Certificate Identification with Change the title on this section to "Certificate Identification
SHA-1". Version 1".
7. Normative References 7. Normative References
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[PKIXCERT] [PKIXCERT]
Housley, R., Ford, W., Polk, W., and D. Solo, "Internet Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
Replace the ASN.1 module with this one.
ExtendedSecurityServices-2006 ExtendedSecurityServices-2006
{ iso(1) member-body(2) us(840) rsadsi(113549) { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess-2006(TBD) } pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-ess-2006(30) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier,
AlgorithmIdentifier AlgorithmIdentifier
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
skipping to change at page 16, line 15 skipping to change at page 17, line 19
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 12 } smime(16) id-aa(2) 12 }
SigningCertificateV2 ::= SEQUENCE { SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2, certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) XX } smime(16) id-aa(2) 47 }
id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) country(16) us(840) organization(1) gov(101)
csor(3) nistalgorithm(4) hashalgs(2) 1 } csor(3) nistalgorithm(4) hashalgs(2) 1 }
ESSCertIDv2 ::= SEQUENCE { ESSCertIDv2 ::= SEQUENCE {
certHash Hash,
hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm
id-sha256 parameters NULL} id-sha256 parameters NULL}
certHash Hash,
issuerSerial IssuerSerial OPTIONAL issuerSerial IssuerSerial OPTIONAL
} }
ESSCertID ::= SEQUENCE { ESSCertID ::= SEQUENCE {
certHash Hash, certHash Hash,
issuerSerial IssuerSerial OPTIONAL issuerSerial IssuerSerial OPTIONAL
} }
Hash ::= OCTET STRING -- SHA1 hash of entire certificate Hash ::= OCTET STRING -- SHA1 hash of entire certificate
skipping to change at page 18, line 5 skipping to change at page 19, line 5
Author's Address Author's Address
Jim Schaad Jim Schaad
Soaring Hawk Consulting Soaring Hawk Consulting
PO Box 675 PO Box 675
Gold Bar, WA 98251 Gold Bar, WA 98251
Phone: (425) 785-1031 Phone: (425) 785-1031
Email: jimsch@exmsft.com Email: jimsch@exmsft.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 18, line 29 skipping to change at page 19, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 29 change blocks. 
57 lines changed or deleted 71 lines changed or added

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