draft-ietf-smime-small-subgroup-00.txt   draft-ietf-smime-small-subgroup-01.txt 
Internet Draft R. Zuccherato(Entrust Technologies) Internet Draft R. Zuccherato(Entrust Technologies)
S/MIME Working Group March 1999 S/MIME Working Group June 1999
expires in six months expires in six months
Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman Methods for Avoiding the "Small-Subgroup" Attacks on the Diffie-Hellman
Key Agreement Method for S/MIME Key Agreement Method for S/MIME
<draft-ietf-smime-small-subgroup-00.txt> <draft-ietf-smime-small-subgroup-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at line 37 skipping to change at line 37
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
In some circumstances the use of the Diffie-Hellman key agreement scheme In some circumstances the use of the Diffie-Hellman key agreement scheme
in a prime order subgroup of a large prime p is vulnerable to certain in a prime order subgroup of a large prime p is vulnerable to certain
attacks known as "small-subgroup" attacks. Methods exist, however, to attacks known as "small-subgroup" attacks. Methods exist, however, to
prevent these attacks. This document will describe the situations prevent these attacks. This document will describe the situations
relevent to the S/MIME standard in which protection is required and the relevant to implementations of S/MIME version 3 in which protection is
methods that can be used to to prevent these attacks. required and the methods that can be used to prevent these attacks.
1. Introduction 1. Introduction
This document will describe those situations in which protection from This document will describe those situations in which protection from
"small-subgroup" type attacks are required when using Diffie-Hellman key "small-subgroup" type attacks are required when using Diffie-Hellman key
agreement as described in [x942] for S/MIME. Thus, the ephemeral-static agreement [x942] in implementations of S/MIME version 3 [CMS, MSG].
modes of Diffie-Hellman will be focussed on. The situations that Thus, the ephemeral-static modes of Diffie-Hellman will be focused on.
require protection are those in which an attacker could determine a The situations that require protection are those in which an attacker
substantial portion (i.e. more than a few bits) of a user's private key. could determine a substantial portion (i.e. more than a few bits) of a
user's private key.
Protecting oneself from these attacks involves certain costs. These Protecting oneself from these attacks involves certain costs. These
costs may include additional processing time either when a public key is costs may include additional processing time either when a public key is
certified or a shared secret key is derived, increased parameter certified or a shared secret key is derived, increased parameter
generation time, increased key size, and possibly the licensing of generation time, increased key size, and possibly the licensing of
encumbered technologies. All of these factors must be considered when
encumbered technologies. All of these factors must be considered when
deciding whether or not to protect oneself from these attacks, or deciding whether or not to protect oneself from these attacks, or
whether to engineer the application so that protection is not required. whether to engineer the application so that protection is not required.
We will not consider "attacks" where the other party in the key We will not consider "attacks" where the other party in the key
agreement merely forces the shared secret value to be "weak" (i.e. from agreement merely forces the shared secret value to be "weak" (i.e. from
a small set of possible values). These types of attacks are not a small set of possible values). It is not worth the effort to attempt
possible to prevent, since the other party may always make the encrypted to prevent these attacks since the other party in the key agreement gets
text public anyway. the shared secret and can simply make the plaintext public.
1.1 Notation 1.1 Notation
In this document we will use the same notation as in [x942]. In In this document we will use the same notation as in [x942]. In
particular the shared secret ZZ is generated as follows: particular the shared secret ZZ is generated as follows:
ZZ = g ^ (xb * xa) mod p ZZ = g ^ (xb * xa) mod p
Note that the individual parties actually perform the computations: Note that the individual parties actually perform the computations:
ZZ = yb ^ xa (mod p) = ya ^ xb mod p ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p
where ^ denotes exponentiation. where ^ denotes exponentiation.
ya is party a's public key; ya = g ^ xa mod p ya is Party A's public key; ya = g ^ xa mod p
yb is party b's public key; yb = g ^ xb mod p yb is Party B's public key; yb = g ^ xb mod p
xa is party a's private key xa is Party A's private key
xb is party b's private key xb is Party B's private key
p is a large prime p is a large prime
g = h^((p-1)/q) mod p, where g = h^((p-1)/q) mod p, where
h is any integer with 1 < h < p-1 such that h^((p-1)/q) mod p > 1 h is any integer with 1 < h < p-1 such that h^((p-1)/q) mod p > 1
(g has order q mod p) (g has order q mod p)
q is a large prime q is a large prime
j a large integer such that p=q*j + 1 j a large integer such that p=q*j + 1
In this discussion, a "static" public key is one that is certified and In this discussion, a "static" public key is one that is certified and
is used for more than one key agreement and an "ephemeral" public key is is used for more than one key agreement, and an "ephemeral" public key
one that is not certified but is used only one time. is one that is not certified but is used only one time.
The order of an integer y modulo p is the smallest value of x greater The order of an integer y modulo p is the smallest value of x greater
than 1 such that y^x=1 mod p. than 1 such that y^x mod p = 1.
1.2 Brief Description of Attack 1.2 Brief Description of Attack
For a complete description of these attacks see [LAW] and [LIM]. For a complete description of these attacks see [LAW] and [LIM].
If the other party in an execution of the Diffie-Hellman key agreement If the other party in an execution of the Diffie-Hellman key agreement
method has a public key not of the form described above, but of small method has a public key not of the form described above, but of small
order (where small means <q) then he/she may be able to obtain order (where small means less than q) then he/she may be able to obtain
information about the user's private key. In particular, if information information about the user's private key. In particular, if information
on whether or not a given decryption was successful is available, or if on whether or not a given decryption was successful is available, or if
ciphertext encrypted with the given key is available, information about ciphertext encrypted with the agreed upon key is available, information
the user's private key can be obtained. about the user's private key can be obtained.
Assume party a has a properly formatted public key ya and that party b Assume Party A has a properly formatted public key ya and that Party B
has a public key yb that is not of the form described in Section 1.1, has a public key yb that is not of the form described in Section 1.1,
but has order r where r<<q. Thus yb^r=1 mod p. Now, when party a rather yb has order r, where r<<q. Thus yb^r=1 mod p. Now, when Party
produces ZZ as yb^xa mod p, there will only be r possible values for ZZ.
If party a encrypts plaintext with this value and makes that ciphertext A produces ZZ as yb^xa mod p, there will only be r possible values for
available to party b, party b only needs to exhaustively search through ZZ instead of p-1 possible values.
If Party A encrypts plaintext with this value and makes that ciphertext
available to Party B, Party B only needs to exhaustively search through
r possibilities to determine which key produced the ciphertext. When r possibilities to determine which key produced the ciphertext. When
the correct one is found, this gives information about the value of xa the correct one is found, this gives information about the value of xa
modulo p. Similarly, if party a uses ZZ to decrypt a ciphertext and modulo r. Similarly, if Party A uses ZZ to decrypt a ciphertext and
relays information about the decryption to party b, information about xa Party B is able to determine whether or not decryption was performed
can be obtained. correctly, then information about xa can be obtained. The actual number
of messages that must be sent or received for these attacks to be
successful will depend on the structure of the prime p. However, it is
not unreasonable to expect that the entire private key could be
determined after as few as one hundred messages.
Also, if party b has a public key of the form yb=g^xb*f where f is an A similar attack can be mounted if Party B chooses a public key of the
element of small order similar attacks are applicable. This is because form yb=g^xb*f, where f is an element of small order. In this situation
party a will now compute ZZ=yb^xa=g^(xa*xb)*f^xa mod p. Again, party b Party A will compute ZZ=yb^xa=g^(xa*xb)*f^xa mod p. Again, Party B can
can compute g^(xa*xb) and therefore only has to exhaust the small number compute g^(xa*xb) and can therefore exhaust the small number of possible
of possible values of f^xa mod p to determine information about xa. values of f^xa mod p to determine information about xa.
2. Situations where protection is required 2. Situations Where Protection Is Required
This section will describe the situations in which the sender of a This section describes the situations in which the sender of a message
message should protect itself against this type of attack and also those should obtain protection against this type of attack and also those
situations in which the receiver of a message should protect itself. situations in which the receiver of a message should obtain protection.
Each entity may decide independently whether it requires protection from Each entity may decide independently whether it requires protection from
these attacks. these attacks.
This discussion assumes that the recipient's key pair is static. This This discussion assumes that the recipient's key pair is static, as is
is the case in [x942]. always the case in [x942].
2.1 For the sender of a message 2.1 Message Sender
If the sender's key is ephemeral (i.e. ephemeral-static Diffie-Hellman This section describes situations in which the message sender should be
protected.
If the sender's key is ephemeral, (i.e. ephemeral-static Diffie-Hellman
is being used), then no protection is required. In this situation only is being used), then no protection is required. In this situation only
the recipient can obtain the plaintext and corresponding ciphertext and the recipients of the message can obtain the plaintext and corresponding
therefore determine information about the private key using the "small- ciphertext and therefore determine information about the private key
subgroup" attacks. However, the recipient can always decrypt the using the "small-subgroup" attacks. However, the recipients can always
message and since the sender's key is ephemeral, even if the recipient decrypt the message and since the sender's key is ephemeral, even if the
can learn the entire private key no other messages are at risk. recipient can learn the entire private key no other messages are at
risk. Notice here that if two or more recipients have selected the same
domain parameters (p,q,g) then the same ephemeral public key can be used
for all of them. Since the key is ephemeral and only associated with a
message that the recipients can already decrypt, no interesting attacks
are possible.
If the sender's key is static (i.e. static-static Diffie-Hellman is If the sender's key is static (i.e. static-static Diffie-Hellman is
being used), then protection is required because in this situation the being used), then protection is required because in this situation a
recipient will obtain the plaintext and corresponding ciphertext and recipient mounting a small-subgroup attack will obtain the plaintext and
therefore could obtain information about the private key using the corresponding ciphertext and therefore could obtain information about
"small-subgroup" attacks. This information could then be used to attack the private key using the "small-subgroup" attacks. This information
other messages protected with this key. could then be used to attack other messages protected with the same
2.2 For the recipient of a message static key.
2.2 Message Recipient
This section describes situations in which the message recipient should
be protected.
If absolutely no information on the decryption of the ciphertext is If absolutely no information on the decryption of the ciphertext is
available to any other party than the recipient then protection is not available to any other party than the recipient, then protection is not
required because this attack requires information on whether the required because this attack requires information on whether the
decryption was successful to be sent to the attacker. In this situation decryption was successful to be sent to the attacker. So, no protective
one must be sure that no information about the decryption can leak out. measures are needed if the implementation ensures that no information
For example, human users may give this information to the sender via out about the decryption can leak out. However, protection may be warranted
of band means (e.g. through telephone conversations). if human users may give this information to the sender via out of band
means (e.g. through telephone conversations).
If information on the decryption is available to any other party , then If information on the decryption is available to any other party , then
protection is required. protection is required.
3. Methods of protection 3. Methods Of Protection
This section lists methods that senders and recipients of messages can This section describes five protective measures that senders and
use to protect themseleves from "small-subgroup" attacks. recipients of messages can use to protect themselves from "small-
subgroup" attacks.
3.1 Public Key Validation 3.1 Public Key Validation
This method is described in Section 2.1.5 of [x942] and its description This method is described in Section 2.1.5 of [x942], and its description
is repeated here. If this method is used, it should be used to validate is repeated here. If this method is used, it should be used to validate
public keys prior to computing the shared secret ZZ. The public key to public keys of the other party prior to computing the shared secret ZZ.
be validated is y. The public key to be validated is y.
1. Verify that y lies within the interval [2,p-1]. If it does not, 1. Verify that y lies within the interval [2,p-1]. If it does not,
the key is invalid. the key is invalid.
2. Compute y^q mod p. If the result == 1, the key is valid. 2. Compute y^q mod p. If the result == 1, the key is valid.
Otherwise the key is invalid. Otherwise the key is invalid.
Note that this procedure may be subject to pending patents. Note that this procedure may be subject to pending patents.
3.2 CA Performs Public Key Validation 3.2 CA Performs Public Key Validation
The CA could perform the Public Key Validation method of Section 3.1 The Certification Authority (CA) could perform the Public Key Validation
once for all entities in a PKI. However, this is only viable for static method described in Section 3.1 prior to signing and issuing a
public keys and thus is always possible as a method of protection for certificate containing a Diffie-Hellman public key. In this way, any
the sender, but only sometimes possible for the receiver (when Static- party using the public key can be assured that a trusted third party has
Static DH is implemented). already performed the key validation process. This method is only
viable for static public keys. When Static-Static Diffie-Hellman is
employed, both the sender and recipient are protected when the CA has
performed public key validation. However, when Ephemeral-Static Diffie-
Hellman is employed, only the sender can be protected. Since the sender
uses an ephemeral public key, the CA cannot perform the validation on
that public key.
In this situation a method must exist to assure the user that the CA has In this situation a method must exist to assure the user that the CA has
actually performed this test. Possibilities include by reference to the actually performed this verification. The CA can notify certificate
CA's Certificate Policy and Certification Practice Statement or through
extensions in the user's certificate. users that it has performed the validation by reference to the CA's
Certificate Policy (CP)and Certification Practice Statement (CPS)
[RFC2527] or through extensions in the certificate.
3.3 Choice of Prime p 3.3 Choice of Prime p
The prime p could be chosen such that p-1=2*q*r where r is the product The prime p could be chosen such that p-1=2*q*j where j is the product
of large primes (large means >=q). This will prevent an attacker from of large primes (large means greater than or equal to q). This will
being able to find an element of small order modulo p and thus mount prevent an attacker from being able to find an element of small order
this attack. To produce primes of this form, the prime generation modulo p, thus thwarting the small-subgroup attack. One method to
algorithm could be run multiple times until a prime with this form is produce primes of this form is to run the prime generation algorithm
obtained. As an example, the value of r could be tested for primality. multiple times until an appropriate prime is obtained. As an example,
If it is prime the value of p could be accepted, otherwise the prime the value of j could be tested for primality. If j is prime, then the
generation algorithm would be run again, until a value of p is produced value of p could be accepted, otherwise the prime generation algorithm
with r prime. would be run again, until a value of p is produced with j prime.
However, since with primes of this form there is still an element of However, since with primes of this form there is still an element of
order 2 (i.e. -1), one bit of the private key could still be lost. order 2 (i.e. -1), one bit of the private key could still be lost.
Thus, this method may not be appropriate in circumstances where even the Thus, this method may not be appropriate in circumstances where the loss
loss of one bit of the private key is a concern. of a single bit of the private key is a concern.
Another option is to choose the prime p such that p = 2*q*r + 1 where r Another method to produce primes of this form is to choose the prime p
is small (i.e. only a few bits). In this case, the leakage due to a such that p = 2*q*j + 1 where j is small (i.e. only a few bits). In this
small subgroup attack will be only a few bits. Again, this would not be case, the leakage due to a small subgroup attack will be only a few
appropriate for circumstances where the loss of even a few bits of the bits. Again, this would not be appropriate for circumstances where the
private key is a concern. loss of even a few bits of the private key is a concern.
3.4 Compatible Cofactor Exponentiation 3.4 Compatible Cofactor Exponentiation
This method of protection is specified in [p1363] and [KALISKI]. It This method of protection is specified in [p1363] and [KALISKI]. It
involves modifying the computation of ZZ. Instead of computing ZZ as involves modifying the computation of ZZ. Instead of computing ZZ as
ZZ=yb^xa mod p, party a would compute it as ZZ=(yb^j)^c mod p where ZZ=yb^xa mod p, Party A would compute it as ZZ=(yb^j)^c mod p where
c=j^(-1)*xa mod q. (Similarly for party b.) c=j^(-1)*xa mod q. (Similarly for Party B.)
If the resulting value ZZ satisfies ZZ==1, then the key agreement should
be abandoned because the public key being used is invalid.
Note that this procedure may be subject to pending patents.
3.5 Non-compatible Cofactor Exponentiation
This method of protection is specified in [p1363]. Similar to the
method of Section 3.4, it involves modifying the computation of ZZ.
Instead of computing ZZ as ZZ=yb^xa mod p, Party A would compute it as
ZZ=(yb^j)^xa mod p. (Similarly for Party B.) However, with this method
the resulting ZZ value is different from what is computed in [x942] and
therefore is not interoperable with implementations conformant to
[x942].
If the resulting value ZZ satisfies ZZ==1, then the key agreement should If the resulting value ZZ satisfies ZZ==1, then the key agreement should
be abandoned because the public key being used is invalid. be abandoned because the public key being used is invalid.
Note that this procedure may be subject to pending patents. Note that this procedure may be subject to pending patents.
4. Ephemeral-Ephemeral Key Agreement 4. Ephemeral-Ephemeral Key Agreement
This situation is when both the sender and recipient of a message are This situation is when both the sender and recipient of a message are
using ephemeral keys. While this situation is not specifically allowed using ephemeral keys. While this situation is not possible in S/MIME,
in S/MIME, some users may however attempt to use this mode and thus we it might be used in other protocol environments. Thus we will briefly
will describe protection for this case as well. discuss protection for this case as well.
In most ephemeral-ephemeral key agreements protection is required for In most ephemeral-ephemeral key agreements protection is required for
both entities. In this situation an attacker could modify the other both entities. In this situation a third party attacker could modify
entity's public key in order to determine the user's private key (as the other entity's public key in order to determine the user's private
described in Section 1.2). Another possibility is that the attacker key (as described in Section 1.2). Another possibility is that the
could modify both parties' public key so as to make their shared key attacker could modify both parties' public key so as to make their
predictable. For example, the attacker could replace both ya and yb shared key predictable. For example, the attacker could replace both ya
with some element of small order, say -1. Then, with a certain and yb with some element of small order, say -1. Then, with a certain
probability, both the sender and receiver would compute the same shared probability, both the sender and receiver would compute the same shared
value which comes from some small, easily exhaustible set. value that comes from some small, easily exhaustible set.
Note that in this situation if protection was obtained from the methods Note that in this situation if protection was obtained from the methods
of Section 3.3, then each user must ensure that the other party's public of Section 3.3, then each user must ensure that the other party's public
key does not come from the small set of elements of small order. This key does not come from the small set of elements of small order. This
can be done either by checking a list of such elements, or by can be done either by checking a list of such elements, or by
additionally applying the methods of Section 3.1. additionally applying the methods of Sections 3.1, 3.4 or 3.5.
Protection from these attacks is not required however if the other Protection from these attacks is not required however if the other
party's ephemeral public key has been signed by the other party. For party's ephemeral public key has been signed by the other party. An
example in the Station-To-Station protocol [STS] no protection is example of this is in the Station-To-Station protocol [STS]. Since the
required because a third party would not be able to alter the other owner authenticates the public key, a third party cannot modify it and
party's public key and thus the only person that could attack the therefore cannot mount an attack. Thus, the only person that could
private key is the other party, who will be able to decrypt the message attack an entity's private key is the other authenticated entity in the
anyway. Since the private key is ephemeral, no other messages would be key agreement. However, since both public keys are ephemeral, they only
compromised even if the entire private key was compromised. protect the current session that the attacker would have access to
anyway.
5. Security Considerations 5. Security Considerations
This entire document concerns security considerations. This entire document addresses security considerations in the
implementation of Diffie-Hellman key agreement.
6. Intellectual Property Rights 6. Intellectual Property Rights
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to per- intellectual property or other rights that might be claimed to per-
tain to the implementation or use of the technology described in this tain to the implementation or use of the technology described in this
document or the extent to which any license under such rights might document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights general license or permission for the use of such proprietary rights
by implementors or users of this specification can be obtained from by implementors or users of this specification can be obtained from
the IETF Secretariat. the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
skipping to change at line 289 skipping to change at line 335
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights general license or permission for the use of such proprietary rights
by implementors or users of this specification can be obtained from by implementors or users of this specification can be obtained from
the IETF Secretariat. the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
7. References 7. References
[RFC2527] S. Chokhani and W. Ford, "Internet X.509 Public Key
Infrastructure, Certificate Policy and Certification Practices
Framework", RFC 2527, March 1999.
[STS] W. Diffie, P.C. van Oorschot and M. Wiener, "Authentication and [STS] W. Diffie, P.C. van Oorschot and M. Wiener, "Authentication and
authenticated key exchanges", Designs, Codes and Cryptography, vol. 2, authenticated key exchanges", Designs, Codes and Cryptography, vol. 2,
1992, pp. 107-125. 1992, pp. 107-125.
[CMS] R. Housley, "Cryptographic Message Syntax", draft-ietf-smime-cms-
XX.txt, work in progress.
[KALISKI] B.S. Kaliski, Jr., "Compatible cofactor multiplication for [KALISKI] B.S. Kaliski, Jr., "Compatible cofactor multiplication for
Diffie-Hellman primitives", Electronics Letters, vol. 34, no. 25, Diffie-Hellman primitives", Electronics Letters, vol. 34, no. 25,
December 10, 1998, pp. 2396-2397. December 10, 1998, pp. 2396-2397.
[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An [LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone, "An
efficient protocol for authenticated key agreement", Technical report efficient protocol for authenticated key agreement", Technical report
CORR 98-05, University of Waterloo, 1998. CORR 98-05, University of Waterloo, 1998.
[LIM] C.H. Lim and P.J. Lee, "A key recovery attack on discrete log- [LIM] C.H. Lim and P.J. Lee, "A key recovery attack on discrete log-
based schemes using a prime order subgroup", B.S. Kaliski, Jr., editor, based schemes using a prime order subgroup", B.S. Kaliski, Jr., editor,
Advances in Cryptology - Crypto '97, Lecture Notes in Computer Science, Advances in Cryptology - Crypto '97, Lecture Notes in Computer Science,
vol. 1295, 1997, Springer-Verlag, pp. 249-263. vol. 1295, 1997, Springer-Verlag, pp. 249-263.
[P1363] IEEE P1363, Standard Specifications for Public Key Cryptography, [P1363] IEEE P1363, Standard Specifications for Public Key Cryptography,
1998, work in progress. 1998, work in progress.
[MSG] B. Ramsdell, "S/MIME Version 3 Message Specification", draft-ietf-
smime-msg-0X.txt, work in progress.
[x942] E. Rescorla, "Diffie-Hellman Key Agreement Method", draft-ietf- [x942] E. Rescorla, "Diffie-Hellman Key Agreement Method", draft-ietf-
smime-x942-0X.txt, work in progress. smime-x942-0X.txt, work in progress.
8. Authors' Addresses 8. Author's Address
Robert Zuccherato Robert Zuccherato
Entrust Technologies Entrust Technologies
750 Heron Road 750 Heron Road
Ottawa, Ontario Ottawa, Ontario
Canada K1V 1A7 Canada K1V 1A7
robert.zuccherato@entrust.com robert.zuccherato@entrust.com
Appendix A. Full Copyright Statement Appendix A. Full Copyright Statement
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/