draft-ietf-smime-3851bis-05.txt   draft-ietf-smime-3851bis-06.txt 
S/MIME WG Blake Ramsdell, SendMail S/MIME WG Blake Ramsdell, Brute Squad Labs
Internet Draft Sean Turner, IECA Internet Draft Sean Turner, IECA
Intended Status: Standard Track August 20, 2008 Intended Status: Standard Track September 18, 2008
Obsoletes: 3851 (when approved) Obsoletes: 3851 (when approved)
Expires: February 20, 2009 Expires: March 18, 2009
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Message Specification Message Specification
draft-ietf-smime-3851bis-05.txt draft-ietf-smime-3851bis-06.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 35 skipping to change at page 1, line 35
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 February 20, 2008. This Internet-Draft will expire on March 18, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines Secure/Multipurpose Internet Mail Extensions This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.2. S/MIME provides a consistent way to send and (S/MIME) version 3.2. S/MIME provides a consistent way to send and
receive secure MIME data. Digital signatures provide authentication, receive secure MIME data. Digital signatures provide authentication,
skipping to change at page 6, line 11 skipping to change at page 6, line 11
time, it is reasonable to expect that if a future revision of a time, it is reasonable to expect that if a future revision of a
document alters the status of a MUST- requirement, it will remain document alters the status of a MUST- requirement, it will remain
at least a SHOULD or a SHOULD-. at least a SHOULD or a SHOULD-.
1.4. Compatibility with Prior Practice of S/MIME 1.4. Compatibility with Prior Practice of S/MIME
S/MIME version 3.2 agents SHOULD attempt to have the greatest S/MIME version 3.2 agents SHOULD attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME. interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive
[SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850 inclusive [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850,
through RFC 3852 and RFC 2634 [SMIMEv3.1]. RFC 2311 also has RFC 3851, RFC 3852, RFC 2634, RFC 4853, and RFC 5035 [SMIMEv3.1].
historical information about the development of S/MIME. RFC 2311 also has historical information about the development of
S/MIME.
1.5. Changes From S/MIME v3 to S/MIME v3.1 1.5. Changes From S/MIME v3 to S/MIME v3.1
The RSA public key algorithm was changed to a MUST implement key The RSA public key algorithm was changed to a MUST implement key
wrapping algorithm, and the Diffie-Hellman algorithm changed to a wrapping algorithm, and the Diffie-Hellman algorithm changed to a
SHOULD implement. SHOULD implement.
The AES symmetric encryption algorithm has been included as a SHOULD The AES symmetric encryption algorithm has been included as a SHOULD
implement. implement.
skipping to change at page 7, line 5 skipping to change at page 7, line 5
Editorial changes, e.g., replaced "MIME type" with "media type", Editorial changes, e.g., replaced "MIME type" with "media type",
content-type with Content-Type. content-type with Content-Type.
Moved "Conventions Used in This Document" to Section 1.2. Added Moved "Conventions Used in This Document" to Section 1.2. Added
definitions for SHOULD+, SHOULD-, and MUST-. definitions for SHOULD+, SHOULD-, and MUST-.
Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA- Sec 1.1 and Appendix A: Added references to RFCs for RSA-PSS, RSA-
OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers OAEP, and SHA2 CMS Algorithms. Added CMS Multiple Signers
Clarification to CMS reference. Clarification to CMS reference.
Sec 1.2: Updated references to ASN.1 to X.680 and BER and DER to Sec 1.3: Updated references to ASN.1 to X.680 and BER and DER to
X.690. X.690.
Sec 1.3: Added references to S/MIME MSG 3.1 RFCs. Sec 1.4: Added references to S/MIME MSG 3.1 RFCs.
Sec 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made Sec 2.1 (digest algorithm): SHA-256 added as MUST, SHA-1 and MD5 made
SHOULD-. SHOULD-.
Sec 2.2 (signature algorithms): RSA with SHA-256 and DSA with SHA-256 Sec 2.2 (signature algorithms): RSA with SHA-256 added as MUST, and
added as MUSTs, RSA with SHA-1, DSA with SHA-1, and RSA with MD5 DSA with SHA-256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1,
changed to SHOULD-, and RSA-PSS with SHA-256 added as SHOULD+. Also and RSA with MD5 changed to SHOULD-, and RSA-PSS with SHA-256 added
added note about what S/MIME v3.1 clients support. as SHOULD+. Also added note about what S/MIME v3.1 clients support.
Sec 2.3 (key encryption): DH changed to SHOULD- and RSA-OAEP added as Sec 2.3 (key encryption): DH changed to SHOULD- and RSA-OAEP added as
SHOULD+. SHOULD+.
Sec 2.5.1: Added requirement that receiving agents MUST support both Sec 2.5.1: Added requirement that receiving agents MUST support both
GeneralizedTime and UTCTime. GeneralizedTime and UTCTime.
Sec 2.5.2: Replaced reference "sha1WithRSAEncrption" with Sec 2.5.2: Replaced reference "sha1WithRSAEncrption" with
"sha256WithRSAEncryption", "DES-3EDE-CBC" and "AES-128 CBC", and "sha256WithRSAEncryption", "DES-3EDE-CBC" with "AES-128 CBC", and
deleted the RC5 example. deleted the RC5 example.
Sec 2.5.2.1, 2.7, 2.7.1, Appendix A: references to RC2/40 removed. Sec 2.5.2.1: Deleted entire section (discussed deprecated RC2).
Sec 2.7, 2.7.1, Appendix A: references to RC2/40 removed.
Sec 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and Sec 2.7 (content encryption): AES-128 CBC added as MUST, AES-192 and
AES-256 CBC SHOULD+, tripleDES now SHOULD-. AES-256 CBC SHOULD+, tripleDES now SHOULD-.
Sec 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1 Sec 2.7.1: Updated pointers from 2.7.2.1 through 2.7.2.4 to 2.7.1.1
to 2.7.1.2. to 2.7.1.2.
Sec 3.2.2: Replaced "encrypted" with "enveloped." Update OID example Sec 3.2.2: Replaced "encrypted" with "enveloped." Update OID example
to use AES-128 CBC oid. to use AES-128 CBC oid.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
Sec 4.1: Updated RSA and DSA key size discussion. Moved last four Sec 4.1: Updated RSA and DSA key size discussion. Moved last four
sentences to security considerations. Updated reference to randomness sentences to security considerations. Updated reference to randomness
requirements for security. requirements for security.
Sec 5: Added IANA registration templates to update media type Sec 5: Added IANA registration templates to update media type
registry to point to this document as opposed to RFC 2311. registry to point to this document as opposed to RFC 2311.
Sec 6: Updated Security Considerations. Sec 6: Updated Security Considerations.
Sec 7: Moved references from Appendix B to this section. Update Sec 7: Moved references from Appendix B to this section. Updated
references. Added informational references to SMIMEv2, SMIMEv3, and references. Added informational references to SMIMEv2, SMIMEv3, and
SMIMEv3.1. SMIMEv3.1.
App B: Added Appendix B to move S/MIME v2 to historic status. App B: Added Appendix B to move S/MIME v2 to historic status.
2. CMS Options 2. CMS Options
CMS allows for a wide variety of options in content, attributes, and CMS allows for a wide variety of options in content, attributes, and
algorithm support. This section puts forth a number of support algorithm support. This section puts forth a number of support
requirements and recommendations in order to achieve a base level of requirements and recommendations in order to achieve a base level of
skipping to change at page 36, line 37 skipping to change at page 36, line 37
software to estimate the actual cost of recovering an encrypted software to estimate the actual cost of recovering an encrypted
message content that is encrypted with a key of a particular size. message content that is encrypted with a key of a particular size.
Further, it is quite difficult to determine the cost of a failed Further, it is quite difficult to determine the cost of a failed
decryption if a recipient cannot process a message's content. Thus, decryption if a recipient cannot process a message's content. Thus,
choosing between different key sizes (or choosing whether to just use choosing between different key sizes (or choosing whether to just use
plaintext) is also impossible for most people or software. However, plaintext) is also impossible for most people or software. However,
decisions based on these criteria are made all the time, and decisions based on these criteria are made all the time, and
therefore this specification gives a framework for using those therefore this specification gives a framework for using those
estimates in choosing algorithms. estimates in choosing algorithms.
The choice of 1024 bits as the RSA, DSA, and DH asymmetric key size The choice of 2048 bits as the RSA asymmetric key size in this
in this specification is based on the desire to provide 80 bits of specification is based on the desire to provide 100 bits of security.
security. This key size seems prudent for the Internet based on The standards to offer the same level of security for DSA and DH are
Section 4.3 of [STRENGTH]. There are other environments (e.g., not yet available. In particular, [FIPS186-3] only defines DSA key
government, financial, and medical) that may consider this key size sizes up to 1024 bits. A revision to support larger key sizes is
to be inadequate. Likewise, there are other environments that may being developed, and once it is available, implementors ought to
consider this key size to be excessive. support DSA key sizes comparable to the RSA key sizes recommended in
this specification. The key sizes that must be supported to conform
to this specification seem appropriate for the Internet based on
[STRENGTH]. Of course, there are environments, such as financial and
medical system, that may select different key sizes. For this
reason, an implementation MAY support key sizes beyond those
recommended in this specification.
Receiving agents that validate signatures and sending agents that Receiving agents that validate signatures and sending agents that
encrypt messages, need to be cautious of cryptographic processing encrypt messages, need to be cautious of cryptographic processing
usage when validating signatures and encrypting messages using keys usage when validating signatures and encrypting messages using keys
larger than those mandated in this specification. An attacker could larger than those mandated in this specification. An attacker could
send certificates with keys which would result in excessive send certificates with keys which would result in excessive
cryptographic processing, for example keys larger than those mandated cryptographic processing, for example keys larger than those mandated
in this specification, which could swamp the processing element. in this specification, which could swamp the processing element.
Agents which use such keys without first validating the certificate Agents which use such keys without first validating the certificate
to a trust anchor are advised to have some sort of cryptographic to a trust anchor are advised to have some sort of cryptographic
resource management system to prevent such attacks. resource management system to prevent such attacks.
Today, 512-bit RSA, DSA, and DH keys are considered by many experts Today, 512-bit RSA, DSA, and DH keys are considered by many experts
to be cryptographically insecure. to be cryptographically insecure.
Using weak cryptography in S/MIME offers little actual security over Using weak cryptography in S/MIME offers little actual security over
sending plaintext. However, other features of S/MIME, such as the sending plaintext. However, other features of S/MIME, such as the
specification of AES and the ability to announce stronger specification of AES and the ability to announce stronger
skipping to change at page 38, line 10 skipping to change at page 38, line 10
Modification of the ciphertext can go undetected if authentication is Modification of the ciphertext can go undetected if authentication is
not also used, which is the case when sending EnvelopedData without not also used, which is the case when sending EnvelopedData without
wrapping it in SignedData or enclosing SignedData within it. wrapping it in SignedData or enclosing SignedData within it.
7. References 7. References
7.1. Normative References 7.1. Normative References
[CERT32] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 [CERT32] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
Certificate Handling", work in progress. Certificate Handling", draft-ietf-smime-3850-bis,
work-in-progress.
[CHARSETS] Character sets assigned by IANA. See [CHARSETS] Character sets assigned by IANA. See
http://www.iana.org/assignments/character-sets http://www.iana.org/assignments/character-sets
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004. 3852, July 2004.
Housley, R., "Cryptographic Message Syntax (CMS) Housley, R., "Cryptographic Message Syntax (CMS)
Multiple Signer Clarification", RFC 4852, April 2007. Multiple Signer Clarification", RFC 4852, April 2007.
skipping to change at page 38, line 43 skipping to change at page 38, line 44
Message Syntax", work in progress. Message Syntax", work in progress.
[CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating [CONTDISP] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August Content-Disposition Header Field", RFC 2183, August
1997. 1997.
[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.
Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", RFC 5035, August 2007.
[FIPS180-3] National Institute of Standards and Technology (NIST), [FIPS180-3] National Institute of Standards and Technology (NIST),
"Secure Hash Standard (SHS)", FIPS Publication 180-3, "Secure Hash Standard (SHS)", FIPS Publication 180-3,
June 2007. June 2007.
[FIPS186-3] National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", FIPS Publication
186-3, March 2006.
[MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet [MIME-SPEC] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
Freed, N. and N. Borenstein, "Multipurpose Internet Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC Mail Extensions (MIME) Part Two: Media Types", RFC
2046, November 1996. 2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996. Non-ASCII Text", RFC 2047, November 1996.
Freed, N., and J. Klensin, , "Multipurpose Internet Freed, N., and J. Klensin, "Multipurpose Internet Mail
Mail Extensions (MIME) Part Four: Registration Extensions (MIME) Part Four: Registration Procedures",
Procedures", BCP 13, RFC 4289, December 2005. BCP 13, RFC 4289, December 2005.
Freed, N., and J. Klensin, "Media Type Specifications Freed, N., and J. Klensin, "Media Type Specifications
and Registration Procedures ", BCP 13, RFC 4288, and Registration Procedures ", BCP 13, RFC 4288,
December 2005. December 2005.
Freed, N. and N. Borenstein, "Multipurpose Internet Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996. and Examples", RFC 2049, November 1996.
[MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed, [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
skipping to change at page 40, line 43 skipping to change at page 40, line 47
Weinstein, "S/MIME Version 2 Certificate Handling", Weinstein, "S/MIME Version 2 Certificate Handling",
RFC 2312, March 1998. RFC 2312, March 1998.
Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, March 1998. RFC 2313, March 1998.
Kaliski, B., "PKCS #10: Certificate Request Syntax Kaliski, B., "PKCS #10: Certificate Request Syntax
Version 1.5", RFC 2314, March 1998. Version 1.5", RFC 2314, March 1998.
Kaliski, B., "PKCS #7: Certificate Message Syntax Kaliski, B., "PKCS #7: Certificate Message Syntax
Version 1.5", RFC 2314, March 1998. Version 1.5", RFC 2315, March 1998.
[SMIMEv3] Housley, R., "Cryptographic Message Syntax", RFC 2630, [SMIMEv3] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999. June 1999.
Rescorla, E., "Diffie-Hellman Key Agreement Method", Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999. RFC 2631, June 1999.
Ramsdell, B., "S/MIME Version 3 Certificate Handling", Ramsdell, B., "S/MIME Version 3 Certificate Handling",
RFC 2632, June 1999. RFC 2632, June 1999.
Ramsdell, B., "S/MIME Version 3 Message Ramsdell, B., "S/MIME Version 3 Message
Specification", RFC 2633, June 1999. Specification", RFC 2633, June 1999.
Hoffman, P., "Enhanced Security Services for S/MIME", Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", RFC 5035, August 2007.
[SMIMEv3.1] Housley, R., "Cryptographic Message Syntax", RFC 3852, [SMIMEv3.1] Housley, R., "Cryptographic Message Syntax", RFC 3852,
July 2004. July 2004.
Housley, R., "Cryptographic Message Syntax (CMS)
Multiple Signer Clarification", RFC 4853, April 2007.
Ramsdell, B., "S/MIME Version 3.1 Certificate Ramsdell, B., "S/MIME Version 3.1 Certificate
Handling", RFC 3850, July 2004. Handling", RFC 3850, July 2004.
Ramsdell, B., "S/MIME Version 3.1 Message Ramsdell, B., "S/MIME Version 3.1 Message
Specification", RFC 3851, July 2004. Specification", RFC 3851, July 2004.
Hoffman, P., "Enhanced Security Services for S/MIME", Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", RFC 5035, August 2007.
[STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For [STRENGTH] Orman, H., and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP Public Keys Used For Exchanging Symmetric Keys", BCP
86, RFC 3766, April 2004. 86, RFC 3766, April 2004.
Appendix A. ASN.1 Module Appendix A. ASN.1 Module
NOTE: The ASN.1 module contained herein is unchanged from RFC 3851 NOTE: The ASN.1 module contained herein is unchanged from RFC 3851
[SMIMEv3.1] with the exception of a minor change to the [SMIMEv3.1] with the exception of a minor change to the
prefersBinaryInside ASN.1 comment. This modules use the 1988 version prefersBinaryInside ASN.1 comment. This modules use the 1988 version
of ASN.1. of ASN.1.
skipping to change at page 44, line 8 skipping to change at page 44, line 8
-- value. -- value.
SMIMECapabilitiesParametersForRC2CBC ::= INTEGER SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
-- (RC2 Key Length (number of bits)) -- (RC2 Key Length (number of bits))
END END
Appendix B. Moving S/MIME v2 Message Specification to Historic Status Appendix B. Moving S/MIME v2 Message Specification to Historic Status
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document)
Message Specifications are backwards S/MIME v2 Message Specification are backwards with the S/MIME v2 Message Specification [SMIMEv2],
[SMIMEv2], with the exception of the algorithms (dropped RC2/40 with the exception of the algorithms (dropped RC2/40 requirement and
requirement and added DSA and RSA-PSS requirements). Therefore, it is added DSA and RSA-PSS requirements). Therefore, it is recommended
recommended that RFC 2311 [SMIMEv2] be moved to Historic status. that RFC 2311 [SMIMEv2] be moved to Historic status.
Appendix C. Acknowledgements Appendix C. Acknowledgements
Many thanks go out to the other authors of the S/MIME Version 2 Many thanks go out to the other authors of the S/MIME Version 2
Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
Lundblade and Lisa Repka. Without v2, there wouldn't be a v3, v3.1 or Lundblade and Lisa Repka. Without v2, there wouldn't be a v3, v3.1 or
v3.2. v3.2.
A number of the members of the S/MIME Working Group have also worked A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is very hard and contributed to this document. Any list of people is
skipping to change at page 44, line 33 skipping to change at page 44, line 33
the following people stand out in my mind due to the fact that they the following people stand out in my mind due to the fact that they
made direct contributions to this document. made direct contributions to this document.
Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter Tony Capel, Piers Chivers, Dave Crocker, Bill Flanigan, Peter
Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway, Gutmann, Alfred Hoenes, Paul Hoffman, Russ Housley, William Ottaway,
John Pawling, and Jim Schaad. John Pawling, and Jim Schaad.
Author's Addresses Author's Addresses
Blake Ramsdell Blake Ramsdell
SendMail Brute Squad Labs, Inc.
Email: blake@sendmail.com Email: blaker@gmail.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
Email: turners@ieca.com Email: turners@ieca.com
 End of changes. 25 change blocks. 
36 lines changed or deleted 61 lines changed or added

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