draft-ietf-smime-cmsalg-02.txt   draft-ietf-smime-cmsalg-03.txt 
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet Draft RSA Laboratories Internet Draft RSA Laboratories
expires in six months August 2001 expires in six months August 2001
Cryptographic Message Syntax (CMS) Algorithms Cryptographic Message Syntax (CMS) Algorithms
<draft-ietf-smime-cmsalg-02.txt> <draft-ietf-smime-cmsalg-03.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. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 4, line 12 skipping to change at page 4, line 12
syntax the OPTIONAL associated with the AlgorithmIdentifier syntax the OPTIONAL associated with the AlgorithmIdentifier
parameters got lost. Later the OPTIONAL was recovered via a defect parameters got lost. Later the OPTIONAL was recovered via a defect
report, but by then many people thought that algorithm parameters report, but by then many people thought that algorithm parameters
were mandatory. Because of this history some implementations encode were mandatory. Because of this history some implementations encode
parameters as a NULL element and others omit them entirely. The parameters as a NULL element and others omit them entirely. The
correct encoding is to omit the parameters field; however, correct encoding is to omit the parameters field; however,
implementations MUST also handle a SHA-1 AlgorithmIdentifier implementations MUST also handle a SHA-1 AlgorithmIdentifier
parameters field which contains a NULL. parameters field which contains a NULL.
The AlgorithmIdentifier parameters field is OPTIONAL. If present, The AlgorithmIdentifier parameters field is OPTIONAL. If present,
the parameters field MUST contain a NULL. Implementations SHOULD the parameters field MUST contain a NULL. Implementations MUST
accept SHA-1 AlgorithmIdentifiers with absent parameters as well as accept SHA-1 AlgorithmIdentifiers with absent parameters.
NULL parameters. Implementations SHOULD generate SHA-1 Implementations SHOULD accept SHA-1 AlgorithmIdentifiers with absent
parameters. Implementations SHOULD generate SHA-1
AlgorithmIdentifiers with absent parameters. AlgorithmIdentifiers with absent parameters.
2.2 MD5 2.2 MD5
The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm The MD5 digest algorithm is defined in RFC 1321 [MD5]. The algorithm
identifier for MD5 is: identifier for MD5 is:
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 } rsadsi(113549) digestAlgorithm(2) 5 }
skipping to change at page 6, line 23 skipping to change at page 6, line 23
When the rsaEncryption algorithm identifier is used, the RSA public When the rsaEncryption algorithm identifier is used, the RSA public
key, which is composed of a modulus and a public exponent, MUST be key, which is composed of a modulus and a public exponent, MUST be
encoded using the RSAPublicKey type. The output of this encoding is encoded using the RSAPublicKey type. The output of this encoding is
carried in the certificate subject public key. carried in the certificate subject public key.
RSAPublicKey ::= SEQUENCE { RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n modulus INTEGER, -- n
publicExponent INTEGER } - e publicExponent INTEGER } - e
CMS implementations that support the RSA (PKCS #1 v1.5) signature CMS implementations that include the RSA (PKCS #1 v1.5) signature
algorithm MUST also support the SHA-1 message digest algorithm. Such algorithm MUST also implement the SHA-1 message digest algorithm.
implementations SHOULD also support MD5 message digest algorithm. Such implementations SHOULD also support MD5 message digest
algorithm.
The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature The algorithm identifier for RSA (PKCS #1 v1.5) with SHA-1 signature
values is: values is:
sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 } us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature The algorithm identifier for RSA (PKCS #1 v1.5) with MD5 signature
values is: values is:
skipping to change at page 7, line 12 skipping to change at page 7, line 12
agreement, key transport, previously distributed symmetric key- agreement, key transport, previously distributed symmetric key-
encryption keys, and passwords. encryption keys, and passwords.
4.1 Key Agreement Algorithms 4.1 Key Agreement Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support key agreement using X9.42 Ephemeral- implementations that support key agreement using X9.42 Ephemeral-
Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie- Static Diffie-Hellman (X9.42 E-S D-H) and X9.42 Static-Static Diffie-
Hellman (X9.42 S-S D-H). Hellman (X9.42 S-S D-H).
Any symmetric encryption algorithm that a CMS implementation includes When a key agreement algorithm is used, a key-encryption algorithm is
as a content-encryption algorithm MUST also be included as a key- also needed. Therefore, when key agreement is supported, a key-
encryption algorithm. The key wrap algorithms for Triple-DES and RC2 encryption algorithm MUST be provided for each content-encryption
are described in section 7. algorithm. The key wrap algorithms for Triple-DES and RC2 are
described in section 7.
A CMS implementation MAY support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption
key MAY be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with
128-bit RC2 key-encryption key.
For key agreement of RC2 key-encryption keys, 128 bits MUST be For key agreement of RC2 key-encryption keys, 128 bits MUST be
generated as input to the key expansion process used to compute the generated as input to the key expansion process used to compute the
RC2 effective key [RC2]. RC2 effective key [RC2].
Key agreement algorithm identifiers are located in the EnvelopedData Key agreement algorithm identifiers are located in the EnvelopedData
RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and RecipientInfos KeyAgreeRecipientInfo keyEncryptionAlgorithm and
AuthenticatedData RecipientInfos KeyAgreeRecipientInfo AuthenticatedData RecipientInfos KeyAgreeRecipientInfo
keyEncryptionAlgorithm fields. keyEncryptionAlgorithm fields.
skipping to change at page 8, line 12 skipping to change at page 8, line 8
originator MUST be the originatorKey alternative. The originator MUST be the originatorKey alternative. The
originatorKey algorithm field MUST contain the dh-public-number originatorKey algorithm field MUST contain the dh-public-number
object identifier with absent parameters. The originatorKey object identifier with absent parameters. The originatorKey
publicKey field MUST contain the sender's ephemeral public key. publicKey field MUST contain the sender's ephemeral public key.
The dh-public-number object identifier is: The dh-public-number object identifier is:
dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2) dh-public-number OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) ansi-x942(10046) number-type(2) 1 } us(840) ansi-x942(10046) number-type(2) 1 }
ukm MAY be present or absent. When present, the ukm is used to ukm may be present or absent. CMS implementations MUST support
ensure that a different key-encryption key is generated when the ukm being absent, and CMS implementations SHOULD support be
ephemeral private key might be used more than once. present. When present, the ukm is used to ensure that a different
key-encryption key is generated when the ephemeral private key
might be used more than once.
keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm keyEncryptionAlgorithm MUST be the id-alg-ESDH algorithm
identifier. The algorithm identifier parameter field for id-alg- identifier. The algorithm identifier parameter field for id-alg-
ESDH is KeyWrapAlgorihtm, and this parameter MUST be present. The ESDH is KeyWrapAlgorithm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key- to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Ephemeral-Static Diffie- encryption key generated using the X9.42 Ephemeral-Static Diffie-
Hellman key agreement algorithm. Triple-DES and RC2 key wrap Hellman key agreement algorithm. Triple-DES and RC2 key wrap
algorithms are discussed in section 7. The id-alg-ESDH algorithm algorithms are discussed in section 7. The id-alg-ESDH algorithm
identifier and parameter syntax is: identifier and parameter syntax is:
id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-alg-ESDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 5 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 5 }
KeyWrapAlgorithm ::= AlgorithmIdentifier KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key. certificate contains the recipient's static public key.
skipping to change at page 9, line 28 skipping to change at page 9, line 26
keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm keyEncryptionAlgorithm MUST be the id-alg-SSDH algorithm
identifier. The algorithm identifier parameter field for id-alg- identifier. The algorithm identifier parameter field for id-alg-
SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The SSDH is KeyWrapAlgorihtm, and this parameter MUST be present. The
KeyWrapAlgorithm denotes the symmetric encryption algorithm used KeyWrapAlgorithm denotes the symmetric encryption algorithm used
to encrypt the content-encryption key with the pairwise key- to encrypt the content-encryption key with the pairwise key-
encryption key generated using the X9.42 Static-Static Diffie- encryption key generated using the X9.42 Static-Static Diffie-
Hellman key agreement algorithm. Triple-DES and RC2 key wrap Hellman key agreement algorithm. Triple-DES and RC2 key wrap
algorithms are discussed in section 7. The id-alg-SSDH algorithm algorithms are discussed in section 7. The id-alg-SSDH algorithm
identifier and parameter syntax is: identifier and parameter syntax is:
id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-alg-SSDH OBJECT IDENTIFIER ::= { iso(1) member-body(2)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 10 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
alg(3) 10 }
KeyWrapAlgorithm ::= AlgorithmIdentifier KeyWrapAlgorithm ::= AlgorithmIdentifier
recipientEncryptedKeys contains an identifier and an encrypted key recipientEncryptedKeys contains an identifier and an encrypted key
for each recipient. The RecipientEncryptedKey for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate. In both cases, the recipient's from the recipient's certificate. In both cases, the recipient's
certificate contains the recipient's static public key. certificate contains the recipient's static public key.
skipping to change at page 11, line 27 skipping to change at page 11, line 27
algorithms that inherently provide authentication ought to be used algorithms that inherently provide authentication ought to be used
with AuthenticatedData. Wrapped content-encryption keys are located with AuthenticatedData. Wrapped content-encryption keys are located
in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo in the EnvelopedData RecipientInfos KeyAgreeRecipientInfo
RecipientEncryptedKeys encryptedKey field, wrapped message- RecipientEncryptedKeys encryptedKey field, wrapped message-
authentication keys are located in the AuthenticatedData authentication keys are located in the AuthenticatedData
RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys RecipientInfos KeyAgreeRecipientInfo RecipientEncryptedKeys
encryptedKey field. encryptedKey field.
4.3.1 Triple-DES Key Wrap 4.3.1 Triple-DES Key Wrap
A CMS implementation MAY support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption
key MAY be wrapped with 168-bit Triple-DES key-encryption key.
Triple-DES key encryption has the algorithm identifier: Triple-DES key encryption has the algorithm identifier:
id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-CMS3DESwrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
The AlgorithmIdentifier parameter field MUST be NULL. The AlgorithmIdentifier parameter field MUST be NULL.
The key wrap algorithm used to encrypt a Triple-DES content- The key wrap algorithm used to encrypt a Triple-DES content-
encryption key with a Triple-DES key-encryption key is specified in encryption key with a Triple-DES key-encryption key is specified in
section 7.2. The corresponding key unwrap algorithm is specified in section 7.2. The corresponding key unwrap algorithm is specified in
section 7.3. section 7.3.
Out-of-band distribution of the Triple-DES key-encryption key used to Out-of-band distribution of the Triple-DES key-encryption key used to
encrypt the Triple-DES content-encryption key is beyond of the scope encrypt the Triple-DES content-encryption key is beyond of the scope
of this document. of this document.
4.3.2 RC2 Key Wrap 4.3.2 RC2 Key Wrap
A CMS implementation MAY support mixed key-encryption and content-
encryption algorithms. For example, a 128-bit RC2 content-encryption
key MAY be wrapped with 168-bit Triple-DES key-encryption key.
Similarly, a 40-bit RC2 content-encryption key MAY be wrapped with
128-bit RC2 key-encryption key.
RC2 key encryption has the algorithm identifier: RC2 key encryption has the algorithm identifier:
id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-alg-CMSRC2wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 } us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 7 }
The AlgorithmIdentifier parameter field MUST be RC2wrapParameter: The AlgorithmIdentifier parameter field MUST be RC2wrapParameter:
RC2wrapParameter ::= RC2ParameterVersion RC2wrapParameter ::= RC2ParameterVersion
RC2ParameterVersion ::= INTEGER RC2ParameterVersion ::= INTEGER
The RC2 effective-key-bits (key size) greater than 32 and less than The RC2 effective-key-bits (key size) greater than 32 and less than
256 is encoded in the RC2ParameterVersion. For the effective-key- 256 is encoded in the RC2ParameterVersion. For the effective-key-
bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120, bits of 40, 64, and 128, the rc2ParameterVersion values are 160, 120,
and 58 respectively. These values are not simply the RC2 key length. and 58 respectively. These values are not simply the RC2 key length.
Note that the value 160 must be encoded as two octets (00 A0), Note that the value 160 must be encoded as two octets (00 A0),
because the one octet (A0) encoding represents a negative number. because the one octet (A0) encoding represents a negative number.
RC2 128-bit keys MUST be used as key-encryption keys, and they MUST RC2 128-bit keys MUST be used as key-encryption keys, and they MUST
skipping to change at page 12, line 32 skipping to change at page 12, line 43
document. document.
4.4 Key Derivation Algorithms 4.4 Key Derivation Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support password-based key management using implementations that support password-based key management using
PBKDF2. PBKDF2.
Key derivation algorithms are used to convert a password into a key- Key derivation algorithms are used to convert a password into a key-
encryption key as part of the password-based key management encryption key as part of the password-based key management
technique. CMS implementations that support the password-based key technique.
management technique MUST implement the PBKDF2 key derivation
algorithm specified in RFC 2898 [PKCS#5].
Key derivation algorithm identifiers are located in the EnvelopedData Key derivation algorithm identifiers are located in the EnvelopedData
RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and RecipientInfos PasswordRecipientInfo keyDerivationAlgorithm and
AuthenticatedData RecipientInfos PasswordRecipientInfo AuthenticatedData RecipientInfos PasswordRecipientInfo
keyDerivationAlgorithm fields. keyDerivationAlgorithm fields.
The key-encryption key that is derived from the password is used to The key-encryption key that is derived from the password is used to
encrypt the content-encryption key encrypt the content-encryption key
The content-encryption keys encrypted with password-derived key- The content-encryption keys encrypted with password-derived key-
encryption keys are located in the EnvelopedData RecipientInfos encryption keys are located in the EnvelopedData RecipientInfos
PasswordRecipientInfo encryptedKey field. The message-authentication PasswordRecipientInfo encryptedKey field. The message-authentication
keys encrypted with password-derived key-encryption keys are located keys encrypted with password-derived key-encryption keys are located
in the AuthenticatedData RecipientInfos PasswordRecipientInfo in the AuthenticatedData RecipientInfos PasswordRecipientInfo
encryptedKey field. encryptedKey field.
4.4.1 PBKDF2 4.4.1 PBKDF2
The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5]. The PBKDF2 key derivation algorithm specified in RFC 2898 [PKCS#5].
skipping to change at page 13, line 24 skipping to change at page 13, line 30
rsadsi(113549) pkcs(1) pkcs-5(5) 12 } rsadsi(113549) pkcs(1) pkcs-5(5) 12 }
The AlgorithmIdentifier parameter field MUST be PBKDF2-params: The AlgorithmIdentifier parameter field MUST be PBKDF2-params:
PBKDF2-params ::= SEQUENCE { PBKDF2-params ::= SEQUENCE {
salt CHOICE { salt CHOICE {
specified OCTET STRING, specified OCTET STRING,
otherSource AlgorithmIdentifier }, otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX), iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL, keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier DEFAULT hMAC-SHA1 } prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
Within the PBKDF2-params, the salt MUST use the specified OCTET
STRING.
5 Content Encryption Algorithms 5 Content Encryption Algorithms
This section specifies the conventions employed by CMS This section specifies the conventions employed by CMS
implementations that support content encryption using Three-Key implementations that support content encryption using Three-Key
Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC Triple-DES in CBC mode, Two-Key Triple-DES in CBC mode, or RC2 in CBC
mode. mode.
Content encryption algorithms identifiers are located in the Content encryption algorithms identifiers are located in the
EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the
skipping to change at page 15, line 8 skipping to change at page 15, line 18
MAC values are located in the AuthenticatedData mac field. MAC values are located in the AuthenticatedData mac field.
6.1 HMAC with SHA-1 6.1 HMAC with SHA-1
The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The The HMAC with SHA-1 algorithm is described in RFC 2104 [HMAC]. The
algorithm identifier for HMAC with SHA-1 is: algorithm identifier for HMAC with SHA-1 is:
hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) hMAC-SHA1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }
The AlgorithmIdentifier parameters field must be absent. There are two possible encodings for the HMAC with SHA-1
AlgorithmIdentifier parameters field. The two alternatives arise
from the fact that when the 1988 syntax for AlgorithmIdentifier was
translated into the 1997 syntax the OPTIONAL associated with the
AlgorithmIdentifier parameters got lost. Later the OPTIONAL was
recovered via a defect report, but by then many people thought that
algorithm parameters were mandatory. Because of this history some
implementations encode parameters as a NULL element and others omit
them entirely. CMS implementations that support HMAC with SHA-1 MUST
handle both an AlgorithmIdentifier parameters field which contains a
NULL and an AlgorithmIdentifier with an absent parameters.
7 Triple-DES and RC2 Key Wrap Algorithms 7 Triple-DES and RC2 Key Wrap Algorithms
This section specifies algorithms for wrapping content-encryption This section specifies algorithms for wrapping content-encryption
keys with Triple-DES and RC2 key-encryption keys. Encryption of a keys with Triple-DES and RC2 key-encryption keys. Encryption of a
Triple-DES content-encryption key with a Triple-DES key-encryption Triple-DES content-encryption key with a Triple-DES key-encryption
key uses the algorithm specified in sections 7.2 and 7.3. Encryption key uses the algorithm specified in sections 7.2 and 7.3. Encryption
of a RC2 content-encryption key with a RC2 key-encryption key uses of a RC2 content-encryption key with a RC2 key-encryption key uses
the algorithm specified in sections 7.4 and 7.5. Both of these the algorithm specified in sections 7.4 and 7.5. Both of these
algorithms rely on the key checksum algorithm specified in section algorithms rely on the key checksum algorithm specified in section
skipping to change at page 18, line 44 skipping to change at page 19, line 19
pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) } pkcs(1) pkcs-9(9) smime(16) modules(0) cmsalg-2001(16) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS All -- EXPORTS All
-- The types and values defined in this module are exported for use in -- The types and values defined in this module are exported for use in
-- the other ASN.1 modules. Other applications may use them for their -- the other ASN.1 modules. Other applications may use them for their
-- own purposes. -- own purposes.
-- IMPORTS None IMPORTS
-- Directory Authentication Framework (X.509-2000)
AlgorithmIdentifier
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 4 } ;
-- Algorithm Identifiers -- Algorithm Identifiers
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 } oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 } rsadsi(113549) digestAlgorithm(2) 5 }
id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
x9-57(10040) x9cm(4) 1 } x9-57(10040) x9cm(4) 1 }
skipping to change at page 21, line 14 skipping to change at page 21, line 42
RC2CBCParameter ::= SEQUENCE { RC2CBCParameter ::= SEQUENCE {
rc2ParameterVersion INTEGER, rc2ParameterVersion INTEGER,
iv OCTET STRING } -- exactly 8 octets iv OCTET STRING } -- exactly 8 octets
PBKDF2-params ::= SEQUENCE { PBKDF2-params ::= SEQUENCE {
salt CHOICE { salt CHOICE {
specified OCTET STRING, specified OCTET STRING,
otherSource AlgorithmIdentifier }, otherSource AlgorithmIdentifier },
iterationCount INTEGER (1..MAX), iterationCount INTEGER (1..MAX),
keyLength INTEGER (1..MAX) OPTIONAL, keyLength INTEGER (1..MAX) OPTIONAL,
prf AlgorithmIdentifier DEFAULT hMAC-SHA1 } prf AlgorithmIdentifier
DEFAULT { algorithm hMAC-SHA1, parameters NULL } }
END -- of CryptographicMessageSyntaxAlgorithms END -- of CryptographicMessageSyntaxAlgorithms
References References
3DES American National Standards Institute. ANSI X9.52-1998, 3DES American National Standards Institute. ANSI X9.52-1998,
Triple Data Encryption Algorithm Modes of Operation. 1998. Triple Data Encryption Algorithm Modes of Operation. 1998.
CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>. <Date>. CMS Housley, R. Cryptographic Message Syntax. RFC <TBD>. <Date>.
{draft-ietf-smime-rfc2630bis-*.txt} {draft-ietf-smime-rfc2630bis-*.txt}
 End of changes. 

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