< draft-ietf-smime-rfc3369bis-02.txt   draft-ietf-smime-rfc3369bis-03.txt >
S/MIME Working Group R. Housley S/MIME Working Group R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
When Approved, Obsoletes: 3369 March 2004 When Approved, Obsoletes: 3369 April 2004
Cryptographic Message Syntax (CMS) Cryptographic Message Syntax (CMS)
<draft-ietf-smime-rfc3369bis-02.txt> <draft-ietf-smime-rfc3369bis-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 20, line 15 skipping to change at page 20, line 15
PKCS #1 v1.5, then a graceful failure must be implemented. PKCS #1 v1.5, then a graceful failure must be implemented.
Implementations MUST support key transport, key agreement, and Implementations MUST support key transport, key agreement, and
previously distributed symmetric key-encryption keys, as represented previously distributed symmetric key-encryption keys, as represented
by ktri, kari, and kekri, respectively. Implementations MAY support by ktri, kari, and kekri, respectively. Implementations MAY support
the password-based key management as represented by pwri. the password-based key management as represented by pwri.
Implementations MAY support any other key management technique as Implementations MAY support any other key management technique as
represented by ori. Since each recipient can employ a different key represented by ori. Since each recipient can employ a different key
management technique and future specifications could define management technique and future specifications could define
additional key management techniques, all implementations MUST additional key management techniques, all implementations MUST
gracefully handle gracefully handle unimplemented alternatives within the RecipientInfo
CHOICE, all implementations MUST gracefully handle unimplemented
unimplemented alternatives within the RecipientInfo CHOICE, all versions of otherwise supported alternatives within the RecipientInfo
implementations MUST gracefully handle unimplemented versions of CHOICE, and all implementations MUST gracefully handle unimplemented
otherwise supported alternatives within the RecipientInfo CHOICE, and or unknown ori alternatives.
all implementations MUST gracefully handle unimplemented or unknown
ori alternatives.
RecipientInfo ::= CHOICE { RecipientInfo ::= CHOICE {
ktri KeyTransRecipientInfo, ktri KeyTransRecipientInfo,
kari [1] KeyAgreeRecipientInfo, kari [1] KeyAgreeRecipientInfo,
kekri [2] KEKRecipientInfo, kekri [2] KEKRecipientInfo,
pwri [3] PasswordRecipientinfo, pwri [3] PasswordRecipientinfo,
ori [4] OtherRecipientInfo } ori [4] OtherRecipientInfo }
EncryptedKey ::= OCTET STRING EncryptedKey ::= OCTET STRING
skipping to change at page 26, line 20 skipping to change at page 26, line 20
oriType identifies the key management technique. oriType identifies the key management technique.
oriValue contains the protocol data elements needed by a recipient oriValue contains the protocol data elements needed by a recipient
using the identified key management technique. using the identified key management technique.
6.3 Content-encryption Process 6.3 Content-encryption Process
The content-encryption key for the desired content-encryption The content-encryption key for the desired content-encryption
algorithm is randomly generated. The data to be protected is padded algorithm is randomly generated. The data to be protected is padded
as described below, as described below, then the padded data is encrypted using the
content-encryption key. The encryption operation maps an arbitrary
then the padded data is encrypted using the content-encryption key. string of octets (the data) to another string of octets (the
The encryption operation maps an arbitrary string of octets (the ciphertext) under control of a content-encryption key. The encrypted
data) to another string of octets (the ciphertext) under control of a data is included in the EnvelopedData encryptedContentInfo
content-encryption key. The encrypted data is included in the encryptedContent OCTET STRING.
EnvelopedData encryptedContentInfo encryptedContent OCTET STRING.
Some content-encryption algorithms assume the input length is a Some content-encryption algorithms assume the input length is a
multiple of k octets, where k is greater than one. For such multiple of k octets, where k is greater than one. For such
algorithms, the input shall be padded at the trailing end with algorithms, the input shall be padded at the trailing end with
k-(lth mod k) octets all having value k-(lth mod k), where lth is k-(lth mod k) octets all having value k-(lth mod k), where lth is
the length of the input. In other words, the input is padded at the length of the input. In other words, the input is padded at
the trailing end with one of the following strings: the trailing end with one of the following strings:
01 -- if lth mod k = k-1 01 -- if lth mod k = k-1
02 02 -- if lth mod k = k-2 02 02 -- if lth mod k = k-2
skipping to change at page 37, line 11 skipping to change at page 37, line 11
The CertificateSet type provides a set of certificates. It is The CertificateSet type provides a set of certificates. It is
intended that the set be sufficient to contain certification paths intended that the set be sufficient to contain certification paths
from a recognized "root" or "top-level certification authority" to from a recognized "root" or "top-level certification authority" to
all of the sender certificates with which the set is associated. all of the sender certificates with which the set is associated.
However, there may be more certificates than necessary, or there MAY However, there may be more certificates than necessary, or there MAY
be fewer than necessary. be fewer than necessary.
The precise meaning of a "certification path" is outside the scope of The precise meaning of a "certification path" is outside the scope of
this document. However, [PROFILE] provides a definition for X.509 this document. However, [PROFILE] provides a definition for X.509
certificates. Some applications may impose upper limits on the certificates. Some applications may impose upper limits on the
length of a length of a certification path; others may enforce certain
relationships between the subjects and issuers of certificates within
certification path; others may enforce certain relationships between a certification path.
the subjects and issuers of certificates within a certification path.
CertificateSet ::= SET OF CertificateChoices CertificateSet ::= SET OF CertificateChoices
10.2.4 IssuerAndSerialNumber 10.2.4 IssuerAndSerialNumber
The IssuerAndSerialNumber type identifies a certificate, and thereby The IssuerAndSerialNumber type identifies a certificate, and thereby
an entity and a public key, by the distinguished name of the an entity and a public key, by the distinguished name of the
certificate issuer and an issuer-specific certificate serial number. certificate issuer and an issuer-specific certificate serial number.
The definition of Name is taken from X.501 [X.501-88], and the The definition of Name is taken from X.501 [X.501-88], and the
 End of changes. 5 change blocks. 
20 lines changed or deleted 16 lines changed or added

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