| < draft-schaad-smime-algorithm-attribute-04.txt | draft-schaad-smime-algorithm-attribute-05.txt > | |||
|---|---|---|---|---|
| Network Working Group J. Schaad | Network Working Group J. Schaad | |||
| Internet-Draft Soaring Hawk Consulting | Internet-Draft Soaring Hawk Consulting | |||
| Intended status: Standards Track January 6, 2011 | Intended status: Standards Track January 24, 2011 | |||
| Expires: July 10, 2011 | Expires: July 28, 2011 | |||
| Signer Info Algorithm Protection Attribute | Cryptographic Messages Syntax (CMS) Algorithm Identifier Protection | |||
| draft-schaad-smime-algorithm-attribute-04 | Attribute | |||
| draft-schaad-smime-algorithm-attribute-05 | ||||
| Abstract | Abstract | |||
| A new attribute is defined that allows for protection of the digest | The Cryptographic Message Syntax (CMS) unlike X.509/PKIX | |||
| and signature algorithm structures in an authenticated data or a | certificates, are venerable to algorithm substitution attacks. In an | |||
| signer info structure. Using the attribute includes the algorithm | algorithm substitution attack, the attacker changes either the | |||
| definition information in the integrity protection process. | algorithm being used or parameters of the algorithm in order to | |||
| change the result of a signature verification process. In X.509 | ||||
| certificates, the signature algorithm is protected because it is | ||||
| duplicated in the TBSCertificate.signature field with the proviso | ||||
| that the validater is to compare both fields as part of the signature | ||||
| validation process. This document defines a new attribute that | ||||
| contains a copy of the relevant algorithm identifiers so that they | ||||
| are protected by the signature or authentication process. | ||||
| Status of this Memo | Status of this Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted 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). 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 July 10, 2011. | This Internet-Draft will expire on July 28, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 18 ¶ | skipping to change at page 2, line 25 ¶ | |||
| 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 6 | 2. Attribute Structure . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 8 | 3. Verification Process . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 8 | 3.1. Signed Data Verification Changes . . . . . . . . . . . . . 8 | |||
| 3.2. Authenticated Data Verification Changes . . . . . . . . . 8 | 3.2. Authenticated Data Verification Changes . . . . . . . . . 8 | |||
| 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 | |||
| 6.2. Informational References . . . . . . . . . . . . . . . . . 11 | 6.2. Informational References . . . . . . . . . . . . . . . . . 11 | |||
| Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 12 | Appendix A. 2008 ASN.1 Module . . . . . . . . . . . . . . . . . . 13 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 1. Introduction | 1. Introduction | |||
| Over past 20 years since the original definition of CMS as PKCS #7 in | The Cryptographic Message Syntax (CMS) [CMS] unlike X.509/PKIX | |||
| 1991, the number of signature and digest algorithms has grown from a | certificates [RFC5280], are venerable to algorithm substitution | |||
| small number to a fairly substantial number and the trend is expected | attacks. In an algorithm substitution attack, the attacker changes | |||
| to accelerate in the future. This has led to a new possible attack | either the algorithm being used or parameters of the algorithm in | |||
| that was not addressed at the time, the algorithm substitution | order to change the result of a signature verification process. In | |||
| attack. In the algorithm substitution attack, the attacker looks for | X.509 certificates, the signature algorithm is protected because it | |||
| collisions not only within the same algorithm as the creator of the | is duplicated in the TBSCertificate.signature field with the proviso | |||
| message used, but in all algorithms that have similar | that the validater is to compare both fields as part of the signature | |||
| characteristics. Thus if the creator of the message used SHA-1 as | validation process. This document defines a new attribute that | |||
| the digest algorithm to hash the content, an attacker could look for | contains a copy of the relevant algorithm identifiers so that they | |||
| collisions in SHA-1, SHA-0 or RIPEMD-160 if those algorithms were in | are protected by the signature or authentication process. | |||
| use at the time the message was created. Once a collision had been | ||||
| found, the attacker would change both the message content and the | ||||
| digest identifier in the message. | ||||
| If one looks at parameterized algorithms, then attacker could also | In an algorithm substitution attack, the attacker looks for a | |||
| potentially attack the set of parameters that are chosen by the | different algorithm that produces the same result as the algorithm | |||
| message creator. We currently have RSASSA-PSS as a parameterized | used by the signer. As an example, if the creator of the message | |||
| signature algorithm and a number different hash algorithms have been | used SHA-1 as the digest algorithm to hash the message content then | |||
| proposed (such as randomized hashing in [RANDOM-HASH]). Part of the | the attacker looks for a different hash algorithm that produces a | |||
| security proof for these algorithms assumes that the attacker does | result that is the same length, but with which it is easier to find | |||
| not have the ability to select the parameters, although in the case | collisions. Examples of other algorithms that produce a hash value | |||
| of a choice of digest algorithms it may influence them. | of the same length would be SHA-0 or RIPEMD-160. Similar attacks can | |||
| be mounted against parameterized algorithm identifiers. When looking | ||||
| at some of the proposed randomized hashing functions, such as that in | ||||
| [RANDOM-HASH], the associated security proofs assume that the | ||||
| parameters are solely under the control of the originator and not | ||||
| subject to selection by the attacker. | ||||
| Algorithm substitution attacks are of greater interest to situations | Some algorithms have been internally designed to be more resistant to | |||
| where messages are expected to be long-lived than for very short term | this type of attack. Thus an RSA PKCS #1 v.15 signature [RFC3447] | |||
| messages. It is much simpler to prove what the current set of | cannot have the associated hash algorithm changed because it is | |||
| constraints of a system are in the present time than it is for a | encoded as part of the signature. DSA was originally defined so that | |||
| great deal of time in the past. Thus this attribute is expected to | it would only work with SHA-1 as a hash algorithm, thus by knowing | |||
| be of greater interest in the timestamping and archiving communities | the public key from the certificate, a validator can be assured that | |||
| than in the S/MIME community. | the hash algorithm can not be changed. There is a convention, | |||
| undocumented as far as I can tell, that the same hash algorithm | ||||
| should be used for both the content digest and the signature digest. | ||||
| There are cases, such as third party signers that are only given a | ||||
| content digest, where such a convention cannot be enforced. | ||||
| In the current definition of [CMS], there are fields that are not | As with all attacks, the attack is going to be desirable on items | |||
| protected for either signature or authentication validation. In this | that are both long term and high value. One would expect that these | |||
| document a new signed or authenticated attribute is defined which | attacks are more likely to be made on older documents as the | |||
| permits these fields to be protected as part of the validation | algorithms being used when the message was signed would be more | |||
| process. | likely to have degraded over time. Countersigning, the classic | |||
| method of protecting a signature does not provide any additional | ||||
| protection against an algorithm substitution attack because | ||||
| countersignatures sign just the signature, but the algorithm | ||||
| substitution attacks leave the signature value alone while changing | ||||
| the algorithms being used. | ||||
| Using the SignerInfo structure from CMS, let's take a more detailed | ||||
| look at each of the fields in the structure and discuss what fields | ||||
| are and are not protected by the signature. I have included a copy | ||||
| of the ASN.1 here for convenience. A similar analysis of the | ||||
| AuthenticatedData structure is left to the reader, but it can be done | ||||
| in much the same way. | ||||
| Using the SignerInfo structure from CMS, let's look at each of the | ||||
| fields in that structure and discuss what is and is not protected by | ||||
| the signature. The ASN.1 is included here for convenience. (The | ||||
| analysis of AuthenticatedData is similar.) | ||||
| SignerInfo ::= SEQUENCE { | SignerInfo ::= SEQUENCE { | |||
| version CMSVersion, | version CMSVersion, | |||
| sid SignerIdentifier, | sid SignerIdentifier, | |||
| digestAlgorithm DigestAlgorithmIdentifier, | digestAlgorithm DigestAlgorithmIdentifier, | |||
| signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, | signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL, | |||
| signatureAlgorithm SignatureAlgorithmIdentifier, | signatureAlgorithm SignatureAlgorithmIdentifier, | |||
| signature SignatureValue, | signature SignatureValue, | |||
| unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } | unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL } | |||
| version is not protected by the signature. Many implementations of | version is not protected by the signature. As many implementations | |||
| CMS today just ignore the value of this field. If the structure | of CMS today ignore the value of this field that is not a problem. | |||
| decodes then this is considered sufficient to continue processing. | If the value is increased, then no changes in the processing are | |||
| Using most decoders on the market the value of this field does not | expected. If the value is decreased, implementations that respect | |||
| control how the decoding is processed. | the structure would fail to decode, but an erroneous signature | |||
| validation would not be completed successfully. | ||||
| sid can be protected by the use of either version of the signing | sid can be protected using either version of the signing certificate | |||
| certificate authenticated attribute. SigningCertificateV2 is | authenticated attribute. SigningCertificateV2 is defined in | |||
| defined in [RFC5035]. SigningCertificate is defined in | [RFC5035]. SigningCertificate is defined in [ESS-BASE]. In | |||
| [ESS-BASE]. In addition to allowing for the protection of the | addition to allowing for the protection of the signer identifier, | |||
| signer identifier, the specific certificate is protected by | the specific certificate is protected by including a hash of the | |||
| including a hash of the certificate to be used for validation. | certificate to be used for validation. | |||
| digestAlgorithm the digest algorithm used has been implicitly | digestAlgorithm the digest algorithm used has been implicitly | |||
| protected by the fact that CMS has only defined one digest | protected by the fact that CMS has only defined one digest | |||
| algorithm for each hash value length. (The algorithm RIPEM-160 | algorithm for each hash value length. (The algorithm RIPEM-160 | |||
| was never standardized). If newer digest algorithms are defined | was never standardized). There is also an unwritten convention | |||
| where there are multiple algorithms for a given hash length, or | that the same digest algorithm should be used both here and for | |||
| where parameters are defined for a specific algorithm, this | the signature algorithm. If newer digest algorithms are defined | |||
| implicit protection will no longer exist. | so that there are multiple algorithms for a given hash length (it | |||
| is expected that the SHA-3 project will do so), or that parameters | ||||
| are defined for a specific algorithm, much of the implicit | ||||
| protection will be lost. | ||||
| signedAttributes are directly protected by the signature when they | signedAttributes are directly protected by the signature when they | |||
| are present. The DER encoding of this value is what is hashed for | are present. The DER encoding of this value is what is hashed for | |||
| the signature computation. | the signature computation. | |||
| signatureAlgorithm has been protected by implication in the past. | signatureAlgorithm has been protected by implication in the past. | |||
| The use of an RSA public key implied that the RSA v 1.5 signature | The use of an RSA public key implied that the RSA v 1.5 signature | |||
| algorithm was being used. The hash algorithm and this fact could | algorithm was being used. The hash algorithm and this fact could | |||
| be checked by the internal padding defined. This is no longer | be checked by the internal padding defined. This is no longer | |||
| true with the addition of the RSA-PSS signature algorithms. The | true with the addition of the RSA-PSS signature algorithms. The | |||
| use of a DSA public key implied the SHA-1 hash algorithm as that | use of a DSA public key implied the SHA-1 hash algorithm as that | |||
| was the only possible hash algorithm and the DSA was the public | was the only possible hash algorithm and the DSA was the public | |||
| signature algorithm. This is longer true with the addition of the | signature algorithm. This is still somewhat true as there is an | |||
| SHA2 signature algorithms. | implicit tie between the length of the DSA public key and the | |||
| length of the hash algorithm to be used, but this is known by | ||||
| convention and there is no explicit enforcement for this. | ||||
| signature is not directly protected by any other value unless a | signature is not directly protected by any other value unless a | |||
| counter signature is present. However this represents the | counter signature is present. However this represents the | |||
| cryptographically computed value that protects the rest of the | cryptographically computed value that protects the rest of the | |||
| signature information. | signature information. | |||
| unsignedAttrs is not protected by the signature value. It is also | unsignedAttrs is not protected by the signature value. It is also | |||
| explicitly designed not to be protected by the signature value. | explicitly designed that they not to be protected by the signature | |||
| value. | ||||
| As can be seen above, the digestAlgorithm and signatureAlgorithm | As can be seen above, the digestAlgorithm and signatureAlgorithm | |||
| fields have been indirectly rather than explicitly protected in the | fields have been indirectly rather than explicitly protected in the | |||
| past. With new algorithms that have been or are being defined this | past. With new algorithms that have been or are being defined this | |||
| will no longer be the case. This document defines and describes a | will no longer be the case. This document defines and describes a | |||
| new attribute that will explicitly protect these fields along with | new attribute that will explicitly protect these fields along with | |||
| the macAlgorithm field of the AuthenticatedData structure. | the macAlgorithm field of the AuthenticatedData structure. | |||
| 1.1. Notation | 1.1. Notation | |||
| skipping to change at page 8, line 7 ¶ | skipping to change at page 8, line 7 ¶ | |||
| unauthenticated attribute or an unprotected attribute. | unauthenticated attribute or an unprotected attribute. | |||
| The SignedAttributes and AuthAttributes syntax are each defined as a | The SignedAttributes and AuthAttributes syntax are each defined as a | |||
| SET of Attributes. The SignedAttributes in a signerInfo MUST include | SET of Attributes. The SignedAttributes in a signerInfo MUST include | |||
| only one instance of the algorithm protection attribute. Similarly, | only one instance of the algorithm protection attribute. Similarly, | |||
| the AuthAttributes in an AuthenticatedData MUST include only one | the AuthAttributes in an AuthenticatedData MUST include only one | |||
| instance of the algorithm protection attribute. | instance of the algorithm protection attribute. | |||
| 3. Verification Process | 3. Verification Process | |||
| The exact verification process depends on the structure being dealt | While the exact verification steps depends on the structure that is | |||
| with. | being validated, there are some common rules that are to be followed | |||
| when comparing the two algorithm structures: | ||||
| When doing comparisons of the fields, a field whose value is a | o A field with a default value MUST compare as being the same | |||
| default value and one which is explicitly provided MUST compare as | independent of whether the value is defaulted or is explicitly | |||
| equivalent. It is not required that a field which is absent in one | provided. | |||
| case and present in another case be compared as equivalent. (This | ||||
| means that an algorithm identifier with absent parameters and one | o It is implementation dependent if, for some algorithms, the | |||
| with NULL parameters are not expected to compare as equivalent.) | absence of a parameter and the presence of a NULL parameter are | |||
| compared as being equivalent. This behavior SHOULD NOT be | ||||
| expected. This is an issue because some implementations will omit | ||||
| a NULL element, while other will encode a NULL element for some | ||||
| digest algorithms such as SHA-1 (see the comments in section 2.1 | ||||
| of [RFC3370]). The issue is even worse because the NULL is absent | ||||
| in some cases ([RFC3370]), but is required in other cases (for | ||||
| example see [RFC4056]). | ||||
| 3.1. Signed Data Verification Changes | 3.1. Signed Data Verification Changes | |||
| If a CMS validator supports this attribute, the following additional | If a CMS validator supports this attribute, the following additional | |||
| verification steps MUST be performed: | verification steps MUST be performed: | |||
| 1. The SignerInfo.digestAlgorithm field MUST be compared to the | 1. The SignerInfo.digestAlgorithm field MUST be compared to the | |||
| digestAlgorithm field in the attribute. If the fields are not the | digestAlgorithm field in the attribute. If the fields are not the | |||
| same (modulo encoding) then signature validation MUST fail. | same (modulo encoding) then signature validation MUST fail. | |||
| skipping to change at page 11, line 26 ¶ | skipping to change at page 11, line 26 ¶ | |||
| [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: | [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: | |||
| Adding CertID Algorithm Agility", RFC 5035, August 2007. | Adding CertID Algorithm Agility", RFC 5035, August 2007. | |||
| [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", | [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", | |||
| RFC 5652, September 2009. | RFC 5652, September 2009. | |||
| [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the | [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the | |||
| Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, | Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, | |||
| June 2010. | June 2010. | |||
| [ASN.1-2008] | ||||
| ITU-T, "ITU-T Recommendations X.680, X.681, X.682, and | ||||
| X.683", 2008. | ||||
| 6.2. Informational References | 6.2. Informational References | |||
| [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) | ||||
| Algorithms", RFC 3370, August 2002. | ||||
| [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography | ||||
| Standards (PKCS) #1: RSA Cryptography Specifications | ||||
| Version 2.1", RFC 3447, February 2003. | ||||
| [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in | ||||
| Cryptographic Message Syntax (CMS)", RFC 4056, June 2005. | ||||
| [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | ||||
| Housley, R., and W. Polk, "Internet X.509 Public Key | ||||
| Infrastructure Certificate and Certificate Revocation List | ||||
| (CRL) Profile", RFC 5280, May 2008. | ||||
| [XOR-HASH] | [XOR-HASH] | |||
| Schaad, J., "Experiment: Hash functions with parameters in | Schaad, J., "Experiment: Hash functions with parameters in | |||
| CMS and S/MIME", draft-schaad-smime-hash-experiment-01 | CMS and S/MIME", draft-schaad-smime-hash-experiment-06 | |||
| (work in progress), December 2009. | (work in progress), January 2011. | |||
| [RANDOM-HASH] | [RANDOM-HASH] | |||
| Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure | Halevi, S. and H. Krawczyk, "Randomized Hashing: Secure | |||
| Digital Signatures without Collision Resistance", IETF 74. | Digital Signatures without Collision Resistance", IETF 74. | |||
| Appendix A. ASN.1 Module | Appendix A. 2008 ASN.1 Module | |||
| The ASN.1 module defined uses the 2008 ASN.1 definitions found in | ||||
| [ASN.1-2008]. This module contains the ASN.1 module which contains | ||||
| the required defintions for the types and values defined in this | ||||
| document. The module uses the ATTRIBUTE class defined in [RFC5912]. | ||||
| CMSAlgorithmProtectionAttribute | CMSAlgorithmProtectionAttribute | |||
| { 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) | pkcs(1) pkcs-9(9) smime(16) modules(0) | |||
| id-mod-cms-algorithmProtect(52) } | id-mod-cms-algorithmProtect(52) } | |||
| DEFINITIONS IMPLICIT TAGS ::= | DEFINITIONS IMPLICIT TAGS ::= | |||
| BEGIN | BEGIN | |||
| IMPORTS | IMPORTS | |||
| -- Cryptographic Message Syntax (CMS) [CMS] | -- Cryptographic Message Syntax (CMS) [CMS] | |||
| skipping to change at page 13, line 4 ¶ | skipping to change at page 14, line 10 ¶ | |||
| id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { | id-aa-cmsAlgorithmProtect OBJECT IDENTIFIER ::= { | |||
| iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) | |||
| pkcs9(9) 52 } | pkcs9(9) 52 } | |||
| CMSAlgorithmProtection ::= SEQUENCE { | CMSAlgorithmProtection ::= SEQUENCE { | |||
| digestAlgorithm DigestAlgorithmIdentifier, | digestAlgorithm DigestAlgorithmIdentifier, | |||
| signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, | signatureAlgorithm [1] SignatureAlgorithmIdentifier OPTIONAL, | |||
| macAlgorithm [2] MessageAuthenticationCodeAlgorithm | macAlgorithm [2] MessageAuthenticationCodeAlgorithm | |||
| OPTIONAL | OPTIONAL | |||
| } | } | |||
| (WITH COMPONENTS { signatureAlgorithm PRESENT, | (WITH COMPONENTS { signatureAlgorithm PRESENT, | |||
| macAlgorithm ABSENT } | | macAlgorithm ABSENT } | | |||
| WITH COMPONENTS { signatureAlgorithm ABSENT, | WITH COMPONENTS { signatureAlgorithm ABSENT, | |||
| macAlgorithm PRESENT }) | macAlgorithm PRESENT }) | |||
| END | END | |||
| Author's Address | Author's Address | |||
| Jim Schaad | Jim Schaad | |||
| Soaring Hawk Consulting | Soaring Hawk Consulting | |||
| PO Box 675 | ||||
| Gold Bar, WA 98251 | ||||
| Email: ietf@augustcellars.com | Email: ietf@augustcellars.com | |||
| End of changes. 23 change blocks. | ||||
| 81 lines changed or deleted | 139 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/ | ||||