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/ |