< draft-ietf-smime-multisig-04.txt   draft-ietf-smime-multisig-05.txt >
S/MIME WG Sean Turner, IECA S/MIME WG Sean Turner, IECA
Internet Draft Jim Schaad, Soaring Hawk Internet Draft Jim Schaad, Soaring Hawk
Intended Status: Standard Track January 22, 2008 Intended Status: Standard Track March 11, 2008
Expires: July 22, 2008 Expires: September 11, 2008
Multiple Signatures in S/MIME Multiple Signatures in S/MIME
draft-ietf-smime-multisig-04.txt draft-ietf-smime-multisig-05.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 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 22, 2008. This Internet-Draft will expire on September 11, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
CMS SignedData includes the SignerInfo structure to convey per-signer Cryptographic Message Syntax (CMS) SignedData includes the SignerInfo
information. SignedData supports multiple signers and multiple structure to convey per-signer information. SignedData supports
signature algorithms per-signer with multiple SignerInfo structures. multiple signers and multiple signature algorithms per-signer with
If a signer attaches more than one SignerInfo, there are concerns multiple SignerInfo structures. If a signer attaches more than one
that an attacker could perform a downgrade attack by removing the SignerInfo, there are concerns that an attacker could perform a
SignerInfo(s) with the 'strong' algorithm(s). This document defines downgrade attack by removing the SignerInfo(s) with the 'strong'
the multiple-signatures attribute, its generation rules, and its algorithm(s). This document defines the multiple-signatures
processing rules to allow signers to convey multiple SignerInfo while attribute, its generation rules, and its processing rules to allow
protecting against downgrade attacks. Additionally, this attribute signers to convey multiple SignerInfo while protecting against
may assist during periods of algorithm migration. downgrade attacks. Additionally, this attribute may assist during
periods of algorithm migration.
Conventions used in this document Conventions used in this document
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].
Discussion Discussion
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
skipping to change at page 3, line 9 skipping to change at page 3, line 9
8.2. Informative References...................................13 8.2. Informative References...................................13
Appendix A. ASN.1 Module.........................................14 Appendix A. ASN.1 Module.........................................14
Appendix B. Background...........................................16 Appendix B. Background...........................................16
B.1. Attacks..................................................16 B.1. Attacks..................................................16
B.2. Hashes in CMS............................................16 B.2. Hashes in CMS............................................16
1. Introduction 1. Introduction
The Cryptographic Message Syntax (CMS), see [CMS], defined SignerInfo The Cryptographic Message Syntax (CMS), see [CMS], defined SignerInfo
to provide data necessary for relying parties to verify the signer's to provide data necessary for relying parties to verify the signer's
digital signature, which is also include in the SignerInfo structure. digital signature, which is also included in the SignerInfo
Signers include more than one SignerInfo in a SignedData if they use structure. Signers include more than one SignerInfo in a SignedData
different digest or signature algorithms. Each SignerInfo exists if they use different digest or signature algorithms. Each SignerInfo
independently and new SignerInfo structures can be added or an exists independently and new SignerInfo structures can be added or an
existing one(s) removed without perturbing the remaining existing one(s) removed without perturbing the remaining
signature(s). signature(s).
The concern is that if an attacker successfully attacked a hash or The concern is that if an attacker successfully attacked a hash or
signature algorithm; the attacker could remove all SignerInfo signature algorithm; the attacker could remove all SignerInfo
structures except the SignerInfo with the successfully attacked hash structures except the SignerInfo with the successfully attacked hash
or signature algorithm; the relying party is then left with the or signature algorithm; the relying party is then left with the
attacked SignerInfo even though the relying party supported more than attacked SignerInfo even though the relying party supported more than
just the attacked hash or signature algorithm. just the attacked hash or signature algorithm.
A solution is to have signers include a pointer to all the signer's A solution is to have signers include a pointer to all the signer's
SignerInfo structures. If an attacker removes any SignerInfo, then SignerInfo structures. If an attacker removes any SignerInfo, then
relying parties will be aware that an attacker has removed one or relying parties will be aware that an attacker has removed one or
more SignerInfo. more SignerInfo.
Note this attribute ought not be confused with the countersignature Note this attribute ought not be confused with the countersignature
attribute, see 11.4 of [CMS], as this is not intended to sign over an attribute, see 11.4 of [CMS], as this is not intended to sign over an
existing signature rather it is to provide a pointer to additional existing signature rather it is to provide a pointer to additional
signer's signatures that are all at the same level. That is signer's signatures that are all at the same level. That is
countersignature provides a serial signature while the attribute countersignature provides a serial signature while the attribute
defined herein provides pointers to parallel signature by the same defined herein provides pointers to parallel signatures by the same
signer. signer.
2. Rationale 2. Rationale
The rationale for this specification is to protect against downgrade The rationale for this specification is to protect against downgrade
attacks that remove the 'strong' signature to leave the 'weak' attacks that remove the 'strong' signature to leave the 'weak'
signature, which has presumably been successfully attacked. If a CMS signature, which has presumably been successfully attacked. If a CMS
object has multiple SignerInfos, then the attacker, whether it be object has multiple SignerInfos, then the attacker, whether it be
Alice, Bob, or Mallory, can remove SignerInfos without the relying Alice, Bob, or Mallory, can remove SignerInfos without the relying
party being aware that more than one was generated. party being aware that more than one was generated.
skipping to change at page 6, line 15 skipping to change at page 6, line 15
The fields in MultipleSignatures have the following meaning: The fields in MultipleSignatures have the following meaning:
- bodyHashAlg includes the digest algorithmIdentifier for the - bodyHashAlg includes the digest algorithmIdentifier for the
referenced multiple-signatures attribute. referenced multiple-signatures attribute.
- signAlg includes the signature algorithmIdentifier for the - signAlg includes the signature algorithmIdentifier for the
referenced multiple-signatures attribute. referenced multiple-signatures attribute.
- signAttrsHash has two fields: - signAttrsHash has two fields:
-- aldId MUST match the digest algorithm for the SignerInfo in -- algId MUST match the digest algorithm for the SignerInfo in
which this multiple-signatures attribute value is placed. which this multiple-signatures attribute value is placed.
-- hash is the hash value of the signedAttrs (see section 4.3). -- hash is the hash value of the signedAttrs (see section 4.3).
- cert is optional. It identities the certificate used to sign the - cert is optional. It identities the certificate used to sign the
SignerInfo that contains the other multiple-signatures SignerInfo that contains the other multiple-signatures
attribute(s). It MUST be present if the fields in the other attribute(s). It MUST be present if the fields in the other
multiple-signatures attribute(s) are the same. multiple-signatures attribute(s) are the same.
The following is an example: The following is an example:
skipping to change at page 8, line 10 skipping to change at page 8, line 10
section 4.4.1 of [CMS] with the following addition: section 4.4.1 of [CMS] with the following addition:
The signer MUST include the multiple-signatures attribute in The signer MUST include the multiple-signatures attribute in
signedAttrs. signedAttrs.
4.4. Message Digest Calculation Process 4.4. Message Digest Calculation Process
4.4.1. multiple-signatures Signed Attribute Generation 4.4.1. multiple-signatures Signed Attribute Generation
The procedure for generating the multiple-signatures signed attribute The procedure for generating the multiple-signatures signed attribute
are as follows: is as follows:
1) All other signed attributes are placed in the respective 1) All other signed attributes are placed in the respective
SignerInfo structures but the signatures are not yet computed for SignerInfo structures but the signatures are not yet computed for
the SignerInfo. the SignerInfo.
2) The multiple-signatures attributes are added to each of the 2) The multiple-signatures attributes are added to each of the
SignerInfo structures with the SignAttrsHash.hash field containing SignerInfo structures with the SignAttrsHash.hash field containing
a zero length octet string. a zero length octet string.
3) The correct SignAttrsHash.hash value is computed for each of the 3) The correct SignAttrsHash.hash value is computed for each of the
skipping to change at page 9, line 5 skipping to change at page 9, line 5
attribute, the attribute's values must be calculated as described in attribute, the attribute's values must be calculated as described in
section 4.4.1. section 4.4.1.
For every SignerInfo to be considered present for a given signer, the For every SignerInfo to be considered present for a given signer, the
number of MultipleSignatures AttributeValue(s) present in a given number of MultipleSignatures AttributeValue(s) present in a given
SignerInfo MUST equal the number of SignerInfos for that signer less SignerInfo MUST equal the number of SignerInfos for that signer less
one and the hash value present in each of the MultipleSignatures one and the hash value present in each of the MultipleSignatures
AttributeValue(s) MUST match the output of the message digest AttributeValue(s) MUST match the output of the message digest
calculation from section 4.4.1 for each SignerInfo. calculation from section 4.4.1 for each SignerInfo.
The hash corresponding to the 1st SignerInfo must match the value in The hash corresponding to the n-th SignerInfo must match the value in
the multiple-signatures attribute that points to the 1st SignerInfo the multiple-signatures attribute that points to the n-th SignerInfo
present in the 2nd and 3rd SignerInfos. The hash corresponding to present in all other SignerInfos.
the 2nd SignerInfo must match the value in the multiple-signatures
attribute that points to the 2nd SignerInfo present in the 1st and
3rd SignerInfos. The hash corresponding to the 3rd SignerInfo must
match the value in the multiple-signatures attribute that points to
the 3rd SignerInfo present in the 1st and 2nd SignerInfos.
5. Signature Evaluation Processing 5. Signature Evaluation Processing
This section describes recommended processing of signatures when This section describes recommended processing of signatures when
there are more than one SignerInfo present in a message. This may be there are more than one SignerInfo present in a message. This may be
due to either multiple SignerInfos being present in a singled due to either multiple SignerInfos being present in a single
SignedData object, or there are multiple SignerData objects embedded SignedData object, or there are multiple SignerData objects embedded
in each other. in each other.
The text in this section is non-normative. The processing described The text in this section is non-normative. The processing described
is highly recommended, but is not forced. Changes in the processing is highly recommended, but is not forced. Changes in the processing
which have the same results with somewhat different orders of which have the same results with somewhat different orders of
processing is sufficient. processing is sufficient.
Order of operations: Order of operations:
skipping to change at page 10, line 11 skipping to change at page 10, line 4
evaluated. The type of things that lead to the last state are non- evaluated. The type of things that lead to the last state are non-
implementation of an algorithm or required inputs, such as the public implementation of an algorithm or required inputs, such as the public
key, are missing. key, are missing.
The second piece is the validation of the source of the public key. The second piece is the validation of the source of the public key.
For CMS, this is generally determined by extracting the public key For CMS, this is generally determined by extracting the public key
from a certificate. The certificate needs to be evaluated. This is from a certificate. The certificate needs to be evaluated. This is
done by the procedures outlined in [PROFILE]. In addition to the done by the procedures outlined in [PROFILE]. In addition to the
processing described in that document, there may be additional processing described in that document, there may be additional
requirements on certification path processing that are required by requirements on certification path processing that are required by
the application in question. One such set of addition processing is the application in question. One such set of additional processing
described in [SMIME-CERT]. One piece of information that is part of is described in [SMIME-CERT]. One piece of information that is part
this additional processing is local and application policy. The of this additional certificate path processing is local and
output of this processing can actually be one of four different application policy. The output of this processing can actually be
states: Success, Failure, Indeterminate and Warning. The first one of four different states: Success, Failure, Indeterminate and
three states are described in [PROFILE], Warning would be generated Warning. The first three states are described in [PROFILE], Warning
when it is possible that some information is currently acceptable, would be generated when it is possible that some information is
but may not be acceptable either in the near future or under some currently acceptable, but may not be acceptable either in the near
circumstances. future or under some circumstances.
The third piece of the validation is local and application policy as The third piece of the validation is local and application policy as
applied to the contents of the SignerInfo object. This would cover applied to the contents of the SignerInfo object. This would cover
such issues as the requirements on mandatory signed attributes or such issues as the requirements on mandatory signed attributes or
requirements on signature algorithms. requirements on signature algorithms.
5.2. Evaluation of a SignerInfo Set 5.2. Evaluation of a SignerInfo Set
Combining the results of the individual SignerInfos into a result for Combining the results of the individual SignerInfos into a result for
a SignedData object requires knowledge of the results for the a SignedData object requires knowledge of the results for the
individual SignerInfo objects, the require application policy and any individual SignerInfo objects, the required application policy and
local policies. The default processing if no other rules are applied any local policies. The default processing if no other rules are
should be: applied should be:
1) Group the SignerInfo objects by the signer. 1) Group the SignerInfo objects by the signer.
2) Take the best result from each signer. 2) Take the best result from each signer.
3) Take the worst result from all of the different signers; this is 3) Take the worst result from all of the different signers; this is
the result for the SignedData object. the result for the SignedData object.
Application and local policy can affect each of the steps outlined Application and local policy can affect each of the steps outlined
above. above.
skipping to change at page 11, line 32 skipping to change at page 11, line 26
makes more sense to try again later if the problem is that a CRL makes more sense to try again later if the problem is that a CRL
cannot be found than if you are not able to evaluate the algorithm cannot be found than if you are not able to evaluate the algorithm
for the signature. for the signature.
In Step 3: In Step 3:
- The same policy implications from Step 2 apply here. - The same policy implications from Step 2 apply here.
5.3. Evaluation of a SignedData Set 5.3. Evaluation of a SignedData Set
For simple applications, the requirement can be made that the result Simple applications will generally use the worst single outcome
of evaluating a set of SignedData objects is the worst outcome of the (success, unknown, failure) as the outcome for a set of SignedData
items. (I.e. one failure means the entire item fails). However not objects (i.e., one failure means the entire item fails). However not
all applications will want to have this behavior. all applications will want to have this behavior.
A work flow application could work as follows: A work flow application could work as follows:
The second signer will modify the original content, keep the The second signer will modify the original content, keep the original
original signature and then sign the message. This means that only signature and then sign the message. This means that only the
the outermost signature is of significance during evaluation. The outermost signature is of significance during evaluation. The second
second signer is asserting that they successfully validated the inner signer is asserting that they successfully validated the inner
signature as part of its processing. signature as part of its processing.
A Signed Mail application could work as follows: A Signed Mail application could work as follows:
If signatures are added for the support of [ESS] features, then the If signatures are added for the support of [ESS] features, then the
fact that an outer layer signature can be treated as a non- fact that an outer layer signature cannot be validated can be treated
significant failure. The only thing that matters is that the as a non-significant failure. The only thing that matters is that
originator signature is valid. This means that all outer layer the originator signature is valid. This means that all outer layer
signatures which fail can be stripped from the message prior to signatures which fail can be stripped from the message prior to
display leaving only the inner-most valid signature to be displayed. display leaving only the inner-most valid signature to be displayed.
6. Security Considerations 6. Security Considerations
Security considerations from the hash and signature algorithms used Security considerations from the hash and signature algorithms used
to produce the SignerInfo apply. to produce the SignerInfo apply.
If the hashing and signing operations are performed by different If the hashing and signing operations are performed by different
entities, the entity performing the signature must ensure the hash entities, the entity performing the signature must ensure the hash
skipping to change at page 16, line 7 skipping to change at page 16, line 7
cert ESSCertIDv2 OPTIONAL } cert ESSCertIDv2 OPTIONAL }
SignAttrsHash ::= SEQUENCE { SignAttrsHash ::= SEQUENCE {
algID DigestAlgorithmIdentifier, algID DigestAlgorithmIdentifier,
hash OCTET STRING } hash OCTET STRING }
END -- of MultipleSignatures-2008 END -- of MultipleSignatures-2008
Appendix B. Background Appendix B. Background
This is an informative appendix that looks at the locations of hashes This is an informational appendix. This appendix enumerates all
CMS and possible attacks against them. locations in CMS where hashes are used and the possible attacks on
those hash locations.
B.1. Attacks B.1. Attacks
The following types of resistance against known attacks, see As noted in [ATTACK], the following types of resistance are needed
[ATTACK], is needed: against known attacks:
1) Collision Resistance: Find x and y where x != y and H(x) = H(y) 1) Collision Resistance: Find x and y where x != y and H(x) = H(y)
2) Preimage Resistance: Given y, find x where H(x) = y 2) Preimage Resistance: Given y, find x where H(x) = y
3) Second Preimage Resistance: Given y, find x where H(x) = H(y) 3) Second Preimage Resistance: Given y, find x where H(x) = H(y)
Note: It is known that a collision resistance attack is simpler than Note: It is known that a collision resistance attack is simpler than
a second preimage resistance attack, and it is presumed that a second a second preimage resistance attack, and it is presumed that a second
preimage resistance attack is simplier than a preimage attack. preimage resistance attack is simplier than a preimage attack.
B.2. Hashes in CMS B.2. Hashes in CMS
Within a SignedInfo there are two places where hashes are applied and Within a SignedInfo there are two places where hashes are applied and
hence can be attacked: the Body and the SignedAttributes. The hence can be attacked: the body and the signed attributes. The
following outlines the entity that creates the hash, the entity that following outlines the entity that creates the hash, the entity that
attacks the hash, and the type of resistance required: attacks the hash, and the type of resistance required:
1) Hash of the Body (i.e., the octets comprising the value of the 1) Hash of the Body (i.e., the octets comprising the value of the
encapContentInfo.eContent OCTET STRING omitting the tag and length encapContentInfo.eContent OCTET STRING omitting the tag and length
octets - as per 5.4 of [CMS]). octets - as per 5.4 of [CMS]).
a) Alice creates the Body to be hashed: a) If Alice creates the body to be hashed, then:
i) Alice attacks the hash: This would require a successful i) Alice can attack the hash. This attack requires a
Collision Resistance attack. successful Collision Resistance attack.
ii) Mallory attacks the hash: This would require a successful ii) Mallory can attack the hash. This attack requires a
Second Preimage Reistance attack. successful Second Preimage Resistance attack.
b) Alice hashes a body provided by Bob: b) If Alice hashes a body provided by Bob, then:
i) Alice attacks the hash: This would require a successful i) Alice can attack the hash. This attack requires a
Second Preimage Attack. successful Second Preimage attack.
ii) Bob attacks the hash: This would require a successful ii) Bob can attack the hash. This attack requires a successful
Collision Resistance attack. This can be upgraded to requiring Collision Resistance attack. If Alice has the ability to
a successful Second Preimage Attack if Alice hash the ability "change" the content of the body in some fashion, then this
to "change" the content of the body in some fashion. (One attack requires a successful Second Preimage attack. (One
example would be to use a keyed hash function.) example would be to use a keyed hash function.)
iii) Mallory attacks the hash: This would require a successful iii) Mallory can attack the hash. This attack requires a
Second Preimage Attack. successful Second Preimage attack.
c) Alice signs using a hash value provided by Bob. (In this case c) If Alice signs using a hash value provided by Bob (in this
Alice is presumed to never see the body in question.) case Alice is presumed to never see the body in question), then:
i) Alice attacks hash: This would require a successful Preimage i) Alice can attack the hash. This attack requires a
Attack. successful Preimage attack.
ii) Bob attacks hash: This would require a successful Collision ii) Bob can attack the hash. This attack requires a successful
Resistance attack. Unlike case (b), there is nothing that Collision Resistance attack. Unlike case (b), there is nothing
Alice can do to upgrade the attack required. that Alice can do to upgrade the attack.
iii) Mallory attacks the hash: This would require a success iii) Mallory can attack the hash. This requires a successful
Preimage attack if the content is unavailable to Mallory and a Preimage attack if the content is unavailable to Mallory and a
successful Second Preimage attack if the content is available successful Second Preimage attack if the content is available
to Mallory. to Mallory.
2) Hash of SignedAttributes (i.e., the complete DER encoding of the 2) Hash of signed attributes (i.e., the complete Distinguished
SignedAttrs value contained in the signedAttrs field - as per 5.4 Encoding Rules (DER) encoding of the SignedAttrs value contained in
of [CMS]). the signedAttrs field - as per 5.4 of [CMS]).
There is a difference between hashing the body and hashing the There is a difference between hashing the body and hashing the
SignedAttrs value in that one SHOULD NOT accept a sequence of SignedAttrs value in that one should not accept a sequence of
attributes to be signed from a third party. In fact one SHOULD NOT attributes to be signed from a third party. In fact one should not
accept attributes to be included in the signed attributes list from a accept attributes to be included in the signed attributes list from
third party. The attributes are about the signature you are applying a third party. The attributes are about the signature you are
and not about the body. If there is meta-information that needs to applying and not about the body. If there is meta-information that
be attached to the body by a third party then they need to provide needs to be attached to the body by a third party then they need to
their own signature and you need to be doing a countersignature. provide their own signature and you need to add a countersignature.
(Note: the fact that the signature is to be used as a (Note: the fact that the signature is to be used as a
countersignature is a piece of information that should be accepted, countersignature is a piece of information that should be accepted,
but it does not directly provide an attribute that is inserted in the but it does not directly provide an attribute that is inserted in
attribute list.) the signed attribute list.)
a) Alice attacks the hash: This requires a successful Collision a) Alice can attack the hash: This requires a successful
Resistance Attack. Collision Resistance Attack.
b) Mallory attacks the hash: This requires a successful Second b) Mallory can attack the hash: This requires a successful
Preimage Resistance attack. Second Preimage Resistance attack.
c) Bob attacks the hash and provides the body hash used: This case c) Bob can attack the hash and knows the body hash used: This
is analogous to the current attacks [ATTACK]. Based on prediction case is analogous to the current attacks [ATTACK]. Based on
of the signed attributes Alice will be using and the provided hash prediction of the signed attributes Alice will be using and the
value and function. (It is expected that if Alice uses a keyed provided hash value and function. (It is expected that if
hashing function as part of the signature this attack will be more Alice uses a keyed hashing function as part of the signature
difficult.) this attack will be more difficult.)
It should be noted that both of these attacks are considered to be It should be noted that both of these attacks are considered to be
more difficult that the attack on the body since more structure is more difficult than the attack on the body since more structure is
designed into the data to be hashed than is frequently found in the designed into the data to be hashed than is frequently found in the
body and the data is shorter in length than that of the body. body and the data is shorter in length than that of the body.
The successful prediction of the Signing-Time attribute is expected The successful prediction of the signing-time attribute is expected
to more difficult than with certificates as the time would not to be more difficult than with certificates as the time would not
generally be rounded. Time stamp services can make this more generally be rounded. Time stamp services can make this more
unpredictable by using a random delay before issuing the signature. unpredictable by using a random delay before issuing the signature.
Allowing a third party to provide a hash value could potentially make Allowing a third party to provide a hash value could potentially make
attack simpler when keyed hash functions are used since there is more an attack simpler when keyed hash functions are used since there is
data than can be modified without changing the overall structure of more data than can be modified without changing the overall structure
the Signed Attribute structure. of the signed attribute structure.
Author's Addresses Author's Addresses
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
 End of changes. 37 change blocks. 
110 lines changed or deleted 107 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/