idnits 2.17.1 draft-ietf-smime-escertid-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 554. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 8 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 21, 2006) is 6611 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'UNIVERSAL 12' is mentioned on line 335, but not defined == Missing Reference: 'UTF8' is mentioned on line 336, but not defined -- Looks like a reference, but probably isn't: '0' on line 483 -- Looks like a reference, but probably isn't: '1' on line 484 -- Looks like a reference, but probably isn't: '2' on line 485 ** Obsolete normative reference: RFC 3280 (ref. 'PKIXCERT') (Obsoleted by RFC 5280) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schaad 3 Internet-Draft Soaring Hawk Consulting 4 Expires: September 22, 2006 March 21, 2006 6 ESS Update: Adding CertID Algorithm Agility 7 draft-ietf-smime-escertid-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 22, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 In the original Enhanged Security Services for S/MIME draft, a 41 structure for cryptographically linking the certificate to be used in 42 validation with the signature was introduced, this structure was 43 hardwired to use SHA-1. This document allows for the structure to 44 have algorithm agility and defines new attributes to deal with the 45 updating. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Replace Section 5.4 Signing Certificate Attribute 52 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Insert new section 5.4.1 . . . . . . . . . . . . . . . . . . . 5 54 4. Insert new section 5.4.1.1 . . . . . . . . . . . . . . . . . . 7 55 5. Insert new section 5.4.2 . . . . . . . . . . . . . . . . . . . 9 56 6. Renumber Section 5.4.1 Certificate Identification . . . . . . 11 57 7. Normative References . . . . . . . . . . . . . . . . . . . . . 11 58 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 60 Intellectual Property and Copyright Statements . . . . . . . . . . 18 62 1. Introduction 64 In the original Enhanged Security Services (ESS) for S/MIME draft 65 [ESS], a structure for cryptographically linking the certificate to 66 be used in validation with the signature was defined. This 67 structure, called ESSCertID was hardwired to use a SHA-1 hash value. 68 The recent attacks on SHA-1 require that we change define a new 69 attribute which allows for the use of a different algorithm. This 70 document performs that task. 72 This document defines the structure ESSCertIDEx along with a new 73 attribute SigningCertificateEx which uses the updated structure. 74 This document allows for the structure to have algorithm agility and 75 defines new attributes to deal with the updating. 77 1.1. Notation 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 2. Replace Section 5.4 Signing Certificate Attribute Definitions 85 The signing certificate attribute is designed to prevent simple 86 substitution and re-issue attacks, and to allow for a restricted set 87 of authorization certificates to be used in verifying a signature. 89 Two different attributes exist for this due to a flaw in the original 90 design. The only substantial difference between the two attributes 91 is that SigningCertificateEx allows for hash algorithm agility, while 92 SigningCertificateEx forces the use of the SHA-1 hash algoirthm. 93 With the recent advances in the ability to create hash collisions for 94 SHA-1 it is deemed wise to move forward sooner rather than later. 96 The SigningCertificateEx attribute is now the perfered attribute to 97 be used. Applications SHOULD use the SigningCertificateEx attribute 98 even if they use SHA-1 as the hash algorithm. Applications SHOULD 99 recognize both attributes as long as they consider SHA-1 to be 100 sufficently stable. 102 3. Insert new section 5.4.1 104 5.4.1 Signing Certificate Attribute Definition 106 The signing certificate attribute is designed to prevent the simple 107 substitution and re-issue attacks, and to allow for a restricted set 108 of authorization certificates to be used in verifying a signature. 110 The definition of SigningCertificateEx is 112 SigningCertificateEx ::= SEQUENCE { 113 certs SEQUENCE OF ESSCertIDEx, 114 policies SEQUENCE OF PolicyInformation OPTIONAL 115 } 117 id-aa-signingCertificateEx OBJECT IDENTIFIER ::= { iso(1) 118 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 119 smime(16) id-aa(2) XX } 121 certs contains the list of certificates that are to be used in 122 validating the message. The first certificate identified in the 123 sequence of certificate identifiers MUST be the certificate used 124 to verify the signature. The encoding of the ESSCertIDEx for this 125 certificate SHOULD include the issuerSerial field. If other 126 constraints ensure that issuerAndSerialNumber will be present in 127 the SignerInfo, the issuerSerial field MAY be omitted. The 128 certificate identified is used during the signature verification 129 process. If the hash of the certificate does not match the 130 certificate used to verify the signature, the signature MUST be 131 considered invalid. 133 If more than one certificate is present, subsiquent certificates 134 limit the set of authorization certificates that are used during 135 signature validation. Authorization certificates can be either 136 attribute certificates or normal certificates. The issuerSerial 137 field (in the ESSCertIDEx structure) SHOULD be present for these 138 certificates, unless the client who is validating the signature is 139 expected to have easy access to all the certificates requred for 140 validation. If only the signing certificate is present in the 141 sequence, there are no restrictions on the set of authorization 142 certificates used in validating the signature. 144 contains a sequence of policy information terms that identify 145 those certificate policies that the signer asserts apply to the 146 certificate, and under which the certificate should be relied 147 upon. This value suggests a policy value to be used in the 148 relying party's certification path validation. The definition of 149 PolicyInformation can be found in [PKIXCERT]. 151 If present, the SigningCertificateEx attribute MUST be a signed 152 attribute; it MUST NOT be an unsigned attribute. CMS defines 153 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 154 include multiple instances of the SigningCertificate attribute. CMS 155 defines the ASN.1 syntax for the signed attributes to include 156 attrValues SET OF AttributeValue. A SigningCertificate attribute 157 MUST include only a single instance of AttributeValue. There MUST 158 NOT be zero or multiple instances of AttributeValue present in the 159 attrValues SET OF AttributeValue. 161 4. Insert new section 5.4.1.1 163 Insert the following text as a new section 165 5.4.1 Certificate Indentification 167 The best way to identify certificates is an often-discussed issue. 168 [PKIXCERT] has imposed a restriction for SignedData objects that the 169 issuer DN must be present in all signing certificates. The issuer/ 170 serial number pair is therefore sufficient to identify the correct 171 signing certificate. This information is already present, as part of 172 the SignerInfo object, and duplication of this information would be 173 unfortunate. A hash of the entire certificate serves the same 174 function (allowing the receiver to verify that the same certificate 175 is being used as when the message was signed), is smaller, and 176 permits a detection of the simple substitution attacks. 178 Attribute certificates and additional public key certificates 179 containing authorization information do not have an issuer/serial 180 number pair represented anywhere in a SignerInfo object. When an 181 attribute certificate or an additional public key certificate is not 182 included in the SignedData object, it becomes much more difficult to 183 get the correct set of certificates based only on a hash of the 184 certificate. For this reason, these certificates SHOULD be 185 identified by the IssuerSerial object. 187 This document defines a certificate identifier as: 189 ESSCertIDEx ::= SEQUENCE { 190 certHash Hash, 191 hashAlg AlgorithmIdentifier DEFAULT {id-sha256}, 192 issuerSerial IssuerSerial OPTIONAL 193 } 195 Hash ::= OCTET STRING 197 IssuerSerial ::= SEQUENCE { 198 issuer GeneralNames, 199 serialNumber CertificateSerialNumber 200 } 202 The fields of ESSCertIDEx are defined as follows: 204 certHash is computed over the entire DER encoded certificate 205 including the signature. The issuerSerial would normally be 206 present unless the value can be inferred from other information. 208 hashAlg contains the identifier of the algorithm used in computing 209 certHash. 211 issuerSerial holds the identification of the certificate. 213 The fields of IssuerSerial are defined as follows: 215 issuer contains the issuer name of the certificate. For non- 216 attribute certificates, the issuer MUST contain only the issuer 217 name from the certificate encoded in the directoryName choice of 218 GeneralNames. For attribute certificates, the issuer MUST contain 219 the issuer name field from the attribute certificate. 221 serialNumber holds the serial number that uniquely identifies the 222 certificate. 224 5. Insert new section 5.4.2 226 5.4.2 Signing Certificate Attribute Definition with SHA-1 228 The signing certificate attribute is designed to prevent the simple 229 substitution and re-issue attacks, and to allow for a restricted set 230 of authorization certificates to be used in verifying a signature. 232 The definition of SigningCertificate is 234 SigningCertificate ::= SEQUENCE { 235 certs SEQUENCE OF ESSCertID, 236 policies SEQUENCE OF PolicyInformation OPTIONAL 237 } 239 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 240 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 241 smime(16) id-aa(2) 12 } 243 The first certificate identified in the sequence of certificate 244 identifiers MUST be the certificate used to verify the signature. 245 The encoding of the ESSCertID for this certificate SHOULD include the 246 issuerSerial field. If other constraints ensure that 247 issuerAndSerialNumber will be present in the SignerInfo, the 248 issuerSerial field MAY be omitted. The certificate identified is 249 used during the signature verification process. If the hash of the 250 certificate does not match the certificate used to verify the 251 signature, the signature MUST be considered invalid. 253 If more than one certificate is present in the sequence of 254 ESSCertIDs, the certificates after the first one limit the set of 255 authorization certificates that are used during signature validation. 256 Authorization certificates can be either attribute certificates or 257 normal certificates. The issuerSerial field (in the ESSCertID 258 structure) SHOULD be present for these certificates, unless the 259 client who is validating the signature is expected to have easy 260 access to all the certificates requred for validation. If only the 261 signing certificate is present in the sequence, there are no 262 restrictions on the set of authorization certificates used in 263 validating the signature. 265 The sequence of policy information terms identifies those certificate 266 policies that the signer asserts apply to the certificate, and under 267 which the certificate should be relied upon. This value suggests a 268 policy value to be used in the relying party's certification path 269 validation. 271 If present, the SigningCertificate attribute MUST be a signed 272 attribute; it MUST NOT be an unsigned attribute. CMS defines 273 SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT 274 include multiple instances of the SigningCertificate attribute. CMS 275 defines the ASN.1 syntax for the signed attributes to include 276 attrValues SET OF AttributeValue. A SigningCertificate attribute 277 MUST include only a single instance of AttributeValue. There MUST 278 NOT be zero or multiple instances of AttributeValue present in the 279 attrValues SET OF AttributeValue. 281 6. Renumber Section 5.4.1 Certificate Identification 283 Change the number on this section from 5.4.1 to 5.4.2.1 285 Change the title on this section to "Certificate Identification with 286 SHA-1". 288 7. Normative References 290 [ESS] Hoffman, P., "Enhanced Security Services for S/MIME", 291 RFC 2634, June 1999. 293 [PKIXCERT] 294 Housley, R., Ford, W., Polk, W., and D. Solo, "Internet 295 X.509 Public Key Infrastructure Certificate and 296 Certificate Revocation List (CRL) Profile", RFC 3280, 297 April 2002. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", RFC 2119, BCP 14, March 1997. 302 Appendix A. ASN.1 Module 304 ExtendedSecurityServices-2006 305 { iso(1) member-body(2) us(840) rsadsi(113549) 306 pkcs(1) pkcs-9(9) smime(16) modules(0) ess-2006(200) } 308 DEFINITIONS IMPLICIT TAGS ::= 309 BEGIN 311 IMPORTS 313 -- Cryptographic Message Syntax (CMS) 314 ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, 315 AlgorithmIdentifier 316 FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) 317 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)} 319 -- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module, 320 -- 1988 Syntax 321 PolicyInformation, CertificateSerialNumber, GeneralNames FROM 322 PKIX1Implicit88 {iso(1) 323 identified-organization(3) dod(6) internet(1) security(5) 324 mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit(19)}; 326 -- Extended Security Services 328 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 329 -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or 330 -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to 331 -- have at least one entry. MAX indicates the upper bound is unspecified. 332 -- Implementations are free to choose an upper bound that suits their 333 -- environment. 335 UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING 336 -- The contents are formatted as described in [UTF8] 338 -- Section 2.7 340 ReceiptRequest ::= SEQUENCE { 341 signedContentIdentifier ContentIdentifier, 342 receiptsFrom ReceiptsFrom, 343 receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames } 345 ub-receiptsTo INTEGER ::= 16 347 id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 348 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1} 350 ContentIdentifier ::= OCTET STRING 351 id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2) 352 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7} 354 ReceiptsFrom ::= CHOICE { 355 allOrFirstTier [0] AllOrFirstTier, 356 -- formerly "allOrNone [0]AllOrNone" 357 receiptList [1] SEQUENCE OF GeneralNames } 359 AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone 360 allReceipts (0), 361 firstTierRecipients (1) } 363 -- Section 2.8 365 Receipt ::= SEQUENCE { 366 version ESSVersion, 367 contentType ContentType, 368 signedContentIdentifier ContentIdentifier, 369 originatorSignatureValue OCTET STRING } 371 id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 372 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} 374 ESSVersion ::= INTEGER { v1(1) } 376 -- Section 2.9 378 ContentHints ::= SEQUENCE { 379 contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL, 380 contentType ContentType } 382 id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 383 rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} 385 -- Section 2.10 387 MsgSigDigest ::= OCTET STRING 389 id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) 390 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} 392 -- Section 2.11 394 ContentReference ::= SEQUENCE { 395 contentType ContentType, 396 signedContentIdentifier ContentIdentifier, 397 originatorSignatureValue OCTET STRING } 399 id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2) 400 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 } 402 -- Section 3.2 404 ESSSecurityLabel ::= SET { 405 security-policy-identifier SecurityPolicyIdentifier, 406 security-classification SecurityClassification OPTIONAL, 407 privacy-mark ESSPrivacyMark OPTIONAL, 408 security-categories SecurityCategories OPTIONAL } 410 id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2) 411 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2} 413 SecurityPolicyIdentifier ::= OBJECT IDENTIFIER 415 SecurityClassification ::= INTEGER { 416 unmarked (0), 417 unclassified (1), 418 restricted (2), 419 confidential (3), 420 secret (4), 421 top-secret (5) } (0..ub-integer-options) 423 ub-integer-options INTEGER ::= 256 425 ESSPrivacyMark ::= CHOICE { 426 pString PrintableString (SIZE (1..ub-privacy-mark-length)), 427 utf8String UTF8String (SIZE (1..MAX)) 428 } 430 ub-privacy-mark-length INTEGER ::= 128 432 SecurityCategories ::= SET SIZE (1..ub-security-categories) OF 433 SecurityCategory 435 ub-security-categories INTEGER ::= 64 437 SecurityCategory ::= SEQUENCE { 438 type [0] OBJECT IDENTIFIER, 439 value [1] ANY DEFINED BY type -- defined by type 440 } 442 --Note: The aforementioned SecurityCategory syntax produces identical 443 --hex encodings as the following SecurityCategory syntax that is 444 --documented in the X.411 specification: 445 -- 446 --SecurityCategory ::= SEQUENCE { 447 -- type [0] SECURITY-CATEGORY, 448 -- value [1] ANY DEFINED BY type } 449 -- 450 --SECURITY-CATEGORY MACRO ::= 451 --BEGIN 452 --TYPE NOTATION ::= type | empty 453 --VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER) 454 --END 456 -- Section 3.4 458 EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel 460 id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2) 461 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9} 463 -- Section 4.4 465 MLExpansionHistory ::= SEQUENCE 466 SIZE (1..ub-ml-expansion-history) OF MLData 468 id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) 469 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} 471 ub-ml-expansion-history INTEGER ::= 64 473 MLData ::= SEQUENCE { 474 mailListIdentifier EntityIdentifier, 475 expansionTime GeneralizedTime, 476 mlReceiptPolicy MLReceiptPolicy OPTIONAL } 478 EntityIdentifier ::= CHOICE { 479 issuerAndSerialNumber IssuerAndSerialNumber, 480 subjectKeyIdentifier SubjectKeyIdentifier } 482 MLReceiptPolicy ::= CHOICE { 483 none [0] NULL, 484 insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, 485 inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } 487 -- Section 5.4 489 SigningCertificate ::= SEQUENCE { 490 certs SEQUENCE OF ESSCertID, 491 policies SEQUENCE OF PolicyInformation OPTIONAL 492 } 493 id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) 494 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 495 smime(16) id-aa(2) 12 } 497 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 498 country(16) us(840) organization(1) gov(101) 499 csor(3) nistalgorithm(4) hashalgs(2) 1 } 501 ESSCertIDEx ::= SEQUENCE { 502 certHash Hash, 503 hashAlgorithm AlgorithmIdentifier DEFAULT {algorithm 504 id-sha256 parameters NULL} 505 issuerSerial IssuerSerial OPTIONAL 506 } 508 ESSCertID ::= SEQUENCE { 509 certHash Hash, 510 issuerSerial IssuerSerial OPTIONAL 511 } 513 Hash ::= OCTET STRING -- SHA1 hash of entire certificate 515 IssuerSerial ::= SEQUENCE { 516 issuer GeneralNames, 517 serialNumber CertificateSerialNumber 518 } 520 END -- of ExtendedSecurityServices-2006 522 Author's Address 524 Jim Schaad 525 Soaring Hawk Consulting 526 PO Box 675 527 Gold Bar, WA 98251 529 Phone: (425) 785-1031 530 Email: jimsch@exmsft.com 532 Intellectual Property Statement 534 The IETF takes no position regarding the validity or scope of any 535 Intellectual Property Rights or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; nor does it represent that it has 539 made any independent effort to identify any such rights. Information 540 on the procedures with respect to rights in RFC documents can be 541 found in BCP 78 and BCP 79. 543 Copies of IPR disclosures made to the IETF Secretariat and any 544 assurances of licenses to be made available, or the result of an 545 attempt made to obtain a general license or permission for the use of 546 such proprietary rights by implementers or users of this 547 specification can be obtained from the IETF on-line IPR repository at 548 http://www.ietf.org/ipr. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary 552 rights that may cover technology that may be required to implement 553 this standard. Please address the information to the IETF at 554 ietf-ipr@ietf.org. 556 Disclaimer of Validity 558 This document and the information contained herein are provided on an 559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 561 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 562 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 563 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 564 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 566 Copyright Statement 568 Copyright (C) The Internet Society (2006). This document is subject 569 to the rights, licenses and restrictions contained in BCP 78, and 570 except as set forth therein, the authors retain all their rights. 572 Acknowledgment 574 Funding for the RFC Editor function is currently provided by the 575 Internet Society.