draft-ietf-smime-ess-08.txt   draft-ietf-smime-ess-09.txt 
Internet Draft Editor: Paul Hoffman Internet Draft Editor: Paul Hoffman
draft-ietf-smime-ess-08.txt Internet Mail Consortium draft-ietf-smime-ess-09.txt Internet Mail Consortium
September 30, 1998 October 19, 1998
Expires in six months Expires in six months
Enhanced Security Services for S/MIME Enhanced Security Services for S/MIME
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working documents This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as groups. Note that other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 46 skipping to change at line 45
The services described here are extensions to S/MIME version 3 [SMIME3], The services described here are extensions to S/MIME version 3 [SMIME3],
and some of them can also be added to S/MIME version 2 [SMIME2]. The and some of them can also be added to S/MIME version 2 [SMIME2]. The
extensions described here will not cause an S/MIME version 3 recipient to extensions described here will not cause an S/MIME version 3 recipient to
be unable to read messages from an S/MIME version 2 sender. However, some be unable to read messages from an S/MIME version 2 sender. However, some
of the extensions will cause messages created by an S/MIME version 3 sender of the extensions will cause messages created by an S/MIME version 3 sender
to be unreadable by an S/MIME version 2 recipient. to be unreadable by an S/MIME version 2 recipient.
The format of the messages are described in ASN.1:1988 [ASN1-1988]. The format of the messages are described in ASN.1:1988 [ASN1-1988].
This draft is being discussed on the "ietf-smime" mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to: subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
in the body of the message. There is a Web site for the mailing list at in the body of the message. There is a Web site for the mailing list at
<http://www.imc.org/ietf-smime/>. <http://www.imc.org/ietf-smime/>.
1.1 Triple Wrapping 1.1 Triple Wrapping
Some of the features of each service use the concept of a "triple wrapped" Some of the features of each service use the concept of a "triple wrapped"
skipping to change at line 456 skipping to change at line 455
2. A signed content identifier for the message is created and assigned to 2. A signed content identifier for the message is created and assigned to
the signedContentIdentifier field. The signedContentIdentifier is used to the signedContentIdentifier field. The signedContentIdentifier is used to
associate the signed receipt with the message requesting the signed associate the signed receipt with the message requesting the signed
receipt. receipt.
3. The entities requested to return a signed receipt are noted in the 3. The entities requested to return a signed receipt are noted in the
receiptsFrom field. receiptsFrom field.
4. The message originator MUST populate the receiptsTo field with a 4. The message originator MUST populate the receiptsTo field with a
GeneralNames for each entity to whom the recipient should send the signed GeneralNames for each entity to whom the recipient should send the signed
receipt. If the message originator wants the recipient to send the signed receipt. If the message originator wants the recipient to send the signed
receipt to the originator, then the originator MUST include a GeneralNames receipt to the originator, then the originator MUST include a GeneralNames
for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF for itself in the receiptsTo field. GeneralNames is a SEQUENCE OF
GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each GeneralName. receiptsTo is a SEQUENCE OF GeneralNames in which each
GeneralNames represents an entity. There may be multiple GeneralName GeneralNames represents an entity. There may be multiple GeneralName
instances in each GeneralNames. At a minimum, the message originator MUST instances in each GeneralNames. At a minimum, the message originator MUST
populate each entity's GeneralNames with the address to which the signed populate each entity's GeneralNames with the address to which the signed
receipt should be sent. Optionally, the message originator MAY also receipt should be sent. Optionally, the message originator MAY also
populate each entity's GeneralNames with other GeneralName instances (such populate each entity's GeneralNames with other GeneralName instances (such
as directoryName). as directoryName).
5. The completed receiptRequest attribute is placed in the signedAttributes 5. The completed receiptRequest attribute is placed in the signedAttributes
field of the SignerInfo object. field of the SignerInfo object.
2.2.1 Multiple Receipt Requests 2.2.1 Multiple Receipt Requests
There can be multiple SignerInfos within a SignedData object, and each There can be multiple SignerInfos within a SignedData object, and each
SignerInfo may include signedAttributes. Therefore, a single SignedData SignerInfo may include signedAttributes. Therefore, a single SignedData
skipping to change at line 900 skipping to change at line 899
-- formerly "allOrNone [0]AllOrNone" -- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames } receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0), allReceipts (0),
firstTierRecipients (1) } firstTierRecipients (1) }
The receiptsTo field is used by the originator to identify the user(s) to The receiptsTo field is used by the originator to identify the user(s) to
whom the identified recipient should send signed receipts. The message whom the identified recipient should send signed receipts. The message
originator MUST populate the receiptsTo field with a GeneralNames for each originator MUST populate the receiptsTo field with a GeneralNames for each
entity to whom the recipient should send the signed receipt. If the message entity to whom the recipient should send the signed receipt. If the message
originator wants the recipient to send the signed receipt to the originator wants the recipient to send the signed receipt to the
originator, then the originator MUST include a GeneralNames for itself in originator, then the originator MUST include a GeneralNames for itself in
the receiptsTo field. the receiptsTo field.
2.8 Receipt Syntax 2.8 Receipt Syntax
Receipts are represented using a new content type, Receipt. The Receipt Receipts are represented using a new content type, Receipt. The Receipt
content type shall have ASN.1 type Receipt. Receipts must be encapsulated content type shall have ASN.1 type Receipt. Receipts must be encapsulated
within a SignedData message. within a SignedData message.
skipping to change at line 933 skipping to change at line 932
2.9 Content Hints 2.9 Content Hints
Many applications find it useful to have information that describes the Many applications find it useful to have information that describes the
innermost signed content of a multi-layer message available on the innermost signed content of a multi-layer message available on the
outermost signature layer. The contentHints attribute provides such outermost signature layer. The contentHints attribute provides such
information. information.
Content-hints attribute values have ASN.1 type contentHints. Content-hints attribute values have ASN.1 type contentHints.
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription UTF8String SIZE (1..MAX) OPTIONAL,   contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
contentType ContentType }   contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
The contentDescription field may be used to provide information that the The contentDescription field may be used to provide information that the
recipient may use to select protected messages for processing, such as a recipient may use to select protected messages for processing, such as a
message subject. If this field is set, then the attribute is expected to message subject. If this field is set, then the attribute is expected to
appear on the signedData object enclosing an envelopedData object and not appear on the signedData object enclosing an envelopedData object and not
on the inner signedData object. The SIZE (1..MAX) construct constrains the on the inner signedData object. The SIZE (1..MAX) construct constrains the
sequence to have at least one entry. MAX indicates the upper bound is sequence to have at least one entry. MAX indicates the upper bound is
skipping to change at line 958 skipping to change at line 957
Messages which contain a signedData object wrapped around an envelopedData Messages which contain a signedData object wrapped around an envelopedData
object, thus masking the inner content type of the message, SHOULD include object, thus masking the inner content type of the message, SHOULD include
a contentHints attribute, except for the case of the data content type. a contentHints attribute, except for the case of the data content type.
Specific message content types may either force or preclude the inclusion Specific message content types may either force or preclude the inclusion
of the contentHints attribute. For example, when a signedData/Receipt is of the contentHints attribute. For example, when a signedData/Receipt is
encrypted within an envelopedData object, an outer signedData object MUST encrypted within an envelopedData object, an outer signedData object MUST
be created that encapsulates the envelopedData object and a contentHints be created that encapsulates the envelopedData object and a contentHints
attribute with contentType set to the id-ct-receipt object identifier MUST attribute with contentType set to the id-ct-receipt object identifier MUST
be included in the outer signedData SignerInfo signedAttributes. be included in the outer signedData SignerInfo signedAttributes.
2.10 Message Signature Digest Attribute 2.10  Message Signature Digest Attribute
The msgSigDigest attribute can only be used in the signed attributes of a The msgSigDigest attribute can only be used in the signed attributes of a
signed receipt. It contains the digest of the ASN.1 DER encoded signed receipt. It contains the digest of the ASN.1 DER encoded
signedAttributes included in the original signedData that requested the signedAttributes included in the original signedData that requested the
signed receipt. Only one msgSigDigest attribute can appear in an signed signed receipt. Only one msgSigDigest attribute can appear in an signed
attributes set. It is defined as follows: attributes set. It is defined as follows:
msgSigDigest ::= OCTET STRING msgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
2.11 Signed Content Reference Attribute 2.11 Signed Content Reference Attribute
The contentReference attribute is a link from one SignedData to another. It The contentReference attribute is a link from one SignedData to another. It
skipping to change at line 1117 skipping to change at line 1116
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString SIZE (1..ub-privacy-mark-length),     pString      PrintableString SIZE (1..ub-privacy-mark-length),
utf8String UTF8String SIZE (1..MAX)     utf8String   UTF8String SIZE (1..MAX)
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
skipping to change at line 1654 skipping to change at line 1653
remembering the value of the mlExpansionHistory and all other remembering the value of the mlExpansionHistory and all other
signed attributes in that layer, if present. signed attributes in that layer, if present.
3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA 3.2.2. If the signed data is EnvelopedData (from step 3.1), the MLA
encapsulates the expanded encrypted message in a new outermost encapsulates the expanded encrypted message in a new outermost
SignedData layer. On the other hand, if the signed data is SignedData layer. On the other hand, if the signed data is
SignedData (from step 3.2), the MLA encapsulates the signed data in SignedData (from step 3.2), the MLA encapsulates the signed data in
a new outermost SignedData layer. a new outermost SignedData layer.
3.2.3. The outermost signedData layer created by the MLA replaces 3.2.3. The outermost signedData layer created by the MLA replaces
the original outermost signedData layer. The MLA MUST create an the original outermost signedData layer. The MLA MUST create an
signed attribute list for the new outermost signedData layer which signed attribute list for the new outermost signedData layer which
MUST include each signed attribute present in the original MUST include each signed attribute present in the original
outermost signedData layer, unless the MLA explicitly replaces one outermost signedData layer, unless the MLA explicitly replaces one
or more particular attributes with new value. A special case is the or more particular attributes with new value. A special case is the
mlExpansionHistory attribute. The MLA MUST add an mlExpansionHistory attribute. The MLA MUST add an
mlExpansionHistory signed attribute to the outer signedData layer mlExpansionHistory signed attribute to the outer signedData layer
as follows: as follows:
3.2.3.1. If the original outermost SignedData layer included an 3.2.3.1. If the original outermost SignedData layer included an
mlExpansionHistory attribute, the attribute's value is copied mlExpansionHistory attribute, the attribute's value is copied
and updated with the current ML expansion information as and updated with the current ML expansion information as
described in the "Mail List Expansion" section. described in the "Mail List Expansion" section.
3.2.3.2. If the original outermost SignedData layer did not 3.2.3.2. If the original outermost SignedData layer did not
include an mlExpansionHistory attribute, a new attribute value include an mlExpansionHistory attribute, a new attribute value
skipping to change at line 1747 skipping to change at line 1746
missing | none insteadOf(B) inAdditionTo(B) missing missing | none insteadOf(B) inAdditionTo(B) missing
*1 = insteadOf(insteadOf(A) + inAdditionTo(B)) *1 = insteadOf(insteadOf(A) + inAdditionTo(B))
*2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B)) *2 = inAdditionTo(inAdditionTo(A) + inAdditionTo(B))
4.4 Mail List Expansion History Syntax 4.4 Mail List Expansion History Syntax
An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If An mlExpansionHistory attribute value has ASN.1 type MLExpansionHistory. If
there are more than ub-ml-expansion-history mailing lists in the sequence, there are more than ub-ml-expansion-history mailing lists in the sequence,
the processing agent should provide notification of the error to a human the processing agent should provide notification of the error to a human
mail list administrator. The mail list administrator is responsible for mail list administrator. The mail list administrator is responsible for
correcting the overflow condition. correcting the overflow condition.
MLExpansionHistory ::= SEQUENCE MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData SIZE (1..ub-ml-expansion-history) OF MLData
id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-mlExpandHistory OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 3}
ub-ml-expansion-history INTEGER ::= 64 ub-ml-expansion-history INTEGER ::= 64
skipping to change at line 1816 skipping to change at line 1815
Attribute certificates can be used as part of a signature verification Attribute certificates can be used as part of a signature verification
process. There is no way in CMS to include the list of attribute process. There is no way in CMS to include the list of attribute
certificates to be used in the verification process. The set of attribute certificates to be used in the verification process. The set of attribute
certificates used in the signature verification process needs to have the certificates used in the signature verification process needs to have the
ability for the signer to restrict the set of certificates. This ability for the signer to restrict the set of certificates. This
information needs to be encoded in a manner that is covered by the information needs to be encoded in a manner that is covered by the
signature on the SignedData object. The methods in this section allows for signature on the SignedData object. The methods in this section allows for
the set of attribute certificates to be listed as part of the signing the set of attribute certificates to be listed as part of the signing
certificate attribute. certificate attribute.
Explicit policies can also be used as part of a signature verification Explicit certificate policies can also be used as part of a signature
process. If a signer desires to state an explicit policy that should be verification process. If a signer desires to state an explicit certificate
used validating the signature, that policy needs to be cryptographically policy that should be used when validating the signature, that policy needs
bound into the signing process. The methods described in this section to be cryptographically bound into the signing process. The methods
allows for a set of policy statements to be listed as part of the signing described in this section allows for a set of certificate policy statements
certificate attribute. to be listed as part of the signing certificate attribute.
5.1. Attack Descriptions 5.1. Attack Descriptions
At least three different attacks can be launched against a possible At least three different attacks can be launched against a possible
signature verification process by changing the certificate or certficates signature verification process by changing the certificate or certficates
used in the signature verification process. used in the signature verification process.
5.1.1 Substitution Attack Description 5.1.1 Substitution Attack Description
The first attack deals with simple substitution of one certificate for The first attack deals with simple substitution of one certificate for
another certificate. In this attack, the issuer and serial number in the another certificate. In this attack, the issuer and serial number in the
SignerInfo is modified to refer to a new certificate. This new certificate SignerInfo is modified to refer to a new certificate. This new certificate
is used the signature verification process. is used during the signature verification process.
The first version of this attack is a simple denial of service attack where The first version of this attack is a simple denial of service attack where
an invalid certificate is substituted for the valid certificate. This an invalid certificate is substituted for the valid certificate. This
renders the message unverifiable, as the public key in the certificate no renders the message unverifiable, as the public key in the certificate no
longer matches the private key used to sign the message. longer matches the private key used to sign the message.
The second version is a substitution of one valid certificate for the The second version is a substitution of one valid certificate for the
original valid certificate where the public keys in the certificates match. original valid certificate where the public keys in the certificates match.
This allows the signature to be validated under potentially different This allows the signature to be validated under potentially different
certificate constraints than the originator of the message intended. certificate constraints than the originator of the message intended.
skipping to change at line 1895 skipping to change at line 1894
from a potentially successful one to simply a denial of service attack. from a potentially successful one to simply a denial of service attack.
5.2.2 Reissue of Certificate Response 5.2.2 Reissue of Certificate Response
A CA should never reissue a certificate with different attributes. A CA should never reissue a certificate with different attributes.
Certificate Authorities that do so are following poor practices and cannot Certificate Authorities that do so are following poor practices and cannot
be relied on. Using the hash of the certificate as the reference to the be relied on. Using the hash of the certificate as the reference to the
certificate prevents this attach for end-entity certificates. certificate prevents this attach for end-entity certificates.
Preventing the attack based on reissuing of CA certificates would require a Preventing the attack based on reissuing of CA certificates would require a
substantial change the attribute presented in section 5.4. It would require substantial change to the usage of the signingCertificate attribute
that a sequence of certificate identifiers be included in the attribute. presented in section 5.4. It would require that ESSCertIDs would need to be
This presents problems when the relying party is using a cross-certificate included in the attribute to represent the issuer certificates in the
as part of its authentication process, and this certificate does not appear signer's certification path. This presents problems when the relying party
on the list of certificates. The problems outside of a closed PKI make the is using a cross-certificate as part of its authentication process, and
addition of this information prone to error, possibly causing the rejection this certificate does not appear on the list of certificates. The problems
of valid chains. outside of a closed PKI make the addition of this information prone to
error, possibly causing the rejection of valid chains.
5.2.3 Rogue Duplicate CA Response 5.2.3 Rogue Duplicate CA Response
The best method of preventing this attack is to avoid trusting the rogue The best method of preventing this attack is to avoid trusting the rogue
CA. The use of the hash to identify certificates prevents the use of CA. The use of the hash to identify certificates prevents the use of
end-entity certificates from the rogue authority. However the only true way end-entity certificates from the rogue authority. However the only true way
to prevent this attack is to never trust the rogue CA. to prevent this attack is to never trust the rogue CA.
5.3 Related Signature Verification Context 5.3 Related Signature Verification Context
skipping to change at line 1949 skipping to change at line 1949
bind that context under the signature. While this could be done by either bind that context under the signature. While this could be done by either
signing the complete certification path or a policy ID, only a binding for signing the complete certification path or a policy ID, only a binding for
the policy ID is described here. the policy ID is described here.
5.4 Signing Certificate Attribute Definition 5.4 Signing Certificate Attribute Definition
The signing certificate attribute is designed to prevent the simple The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set of substitution and re-issue attacks, and to allow for a restricted set of
attribute certificates to be used in verifying a signature. attribute certificates to be used in verifying a signature.
The following object identifier identifies the encrypted-data content type:
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) <TBD> }
The definition of SigningCertificate is The definition of SigningCertificate is
SigningCertificate ::= SEQUENCE { SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF CertID, certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) <TBD> }
The first certificate identified in the sequence of certificate identifiers The first certificate identified in the sequence of certificate identifiers
MUST be the certificate used to verify the signature. The encoding of the MUST be the certificate used to verify the signature. The encoding of the
CertID for this certificate SHOULD NOT include the issuerAndSerialNumber ESSCertID for this certificate SHOULD NOT include the issuerSerial because
because the issuerAndSerialNumber is already present in the SignerInfo. The the issuerAndSerialNumber is already present in the SignerInfo. The
certificate identified is used during the signature verification process. certificate identified is used during the signature verification process.
If the hash of the certificate does not match the certificate used to If the hash of the certificate does not match the certificate used to
decode the signature, the signature MUST be considered invalid. verify the signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of CertIDs, the If more than one certificate is present in the sequence of ESSCertIDs, the
certificates after the first one limit the set of attribute certificates certificates after the first one limit the set of attribute certificates
that are used during signature validation. The issuerAndSerialNumber SHOULD that are used during signature validation. The issuerSerial SHOULD be
be present in these certificates, unless the client who is validating the present in these certificates, unless the client who is validating the
signature is expected to have easy access to all the certificates required signature is expected to have easy access to all the certificates required
for validation. If only the signing certificate is present in the sequence. for validation. If only the signing certificate is present in the sequence.
there are no restrictions on the set of attribute certificates used in there are no restrictions on the set of attribute certificates used in
validating the signature. validating the signature.
The sequence of policy information terms identifies those certificate The sequence of policy information terms identifies those certificate
policies that the signer asserts apply to the certificate, and under which policies that the signer asserts apply to the certificate, and under which
the certificate should be relied upon. This value suggests a policy value the certificate should be relied upon. This value suggests a policy value
to be used in the relying party's certification path validation. to be used in the relying party's certification path validation.
skipping to change at line 2001 skipping to change at line 1999
AttributeValue present in the attrValues SET OF AttributeValue. AttributeValue present in the attrValues SET OF AttributeValue.
5.4.1 Certificate Identification 5.4.1 Certificate Identification
The best way to identify certificates is an often-discussed issue. [CMS] The best way to identify certificates is an often-discussed issue. [CMS]
has imposed a restriction for SignedData objects that the issuer DN must be has imposed a restriction for SignedData objects that the issuer DN must be
present in all signing certificates. The issuer/serial number pair is present in all signing certificates. The issuer/serial number pair is
therefore sufficient to identify the correct signing certificate. This therefore sufficient to identify the correct signing certificate. This
information is already present, as part of the SignerInfo object, and information is already present, as part of the SignerInfo object, and
duplication of this information would be unfortunate. A hash of the entire duplication of this information would be unfortunate. A hash of the entire
certificate serves the same function (allowing the receiver to very the certificate serves the same function (allowing the receiver to verify that
same certificate is being used), is smaller and permits a detection of the the same certificate is being used as when the message was signed), is
simple substitution attacks. smaller, and permits a detection of the simple substitution attacks.
Attribute certificates do not have an issuer/serial number pair represented Attribute certificates do not have an issuer/serial number pair represented
anywhere in a SignerInfo object. When an attribute certificate is not anywhere in a SignerInfo object. When an attribute certificate is not
included in the SignedData object, it becomes much more difficult to get included in the SignedData object, it becomes much more difficult to get
the correct set of certificates based only on a hash of the certificate. the correct set of certificates based only on a hash of the certificate.
For this reason, attribute certificates are identified by the IssuerSerial For this reason, attribute certificates are identified by the IssuerSerial
object. object.
This document defines a certificate identifier as: This document defines a certificate identifier as:
CertID ::= SEQUENCE { ESSCertID ::= SEQUENCE {
certHash Hash, certHash Hash,
issuerSerial IssuerSerial OPTIONAL issuerSerial IssuerSerial OPTIONAL
} }
Hash ::= OCTET STRING -- SHA1 hash of entire certificate Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE { IssuerSerial ::= SEQUENCE {
issuer GeneralNames, issuer GeneralNames,
serialNumber CertificateSerialNumber serialNumber CertificateSerialNumber
} }
When creating a CertID, the certHash is computed over the entire DER When creating an ESSCertID, the certHash is computed over the entire DER
encoded certificate including the signature. The issuerSerial would encoded certificate including the signature. The issuerSerial would
normally be present unless the value can be inferred from other normally be present unless the value can be inferred from other
information. information.
When encoding IssuerSerial, serialNumber is the serial number that uniquely When encoding IssuerSerial, serialNumber is the serial number that uniquely
identifies the certificate. For non-attribute certificates, the issuer MUST identifies the certificate. For non-attribute certificates, the issuer MUST
contain only the issuer name from the certificate encoded in the contain only the issuer name from the certificate encoded in the
directoryName choice of GeneralNames. For attribute certificates, the directoryName choice of GeneralNames. For attribute certificates, the
issuer MUST contain the issuer name field from the attribute certificate. issuer MUST contain the issuer name field from the attribute certificate.
skipping to change at line 2057 skipping to change at line 2055
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
-- Cryptographic Message Syntax (CMS) -- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, Version ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier, Version
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840) FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) } rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1) }
-- PKIX Certificate and CRL Profile, Sec A.2 Implicitly Tagged Module,
-- 1988 Syntax
PolicyInformation FROM PKIX1Implicit88 {iso(1
identified-organization(3)dod(6) internet(1) security(5)
mechanisms(5) pkix(7)id-mod(0) id-pkix1-implicit-88(2)}
-- X.509 -- X.509
GeneralNames FROM CertificateExtensions GeneralNames, CertificateSerialNumber, FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0}; {joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- Extended Security Services -- Extended Security Services
-- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1 -- The construct "SEQUENCE SIZE (1..MAX) OF" appears in several ASN.1
-- constructs in this module. A valid ASN.1 SEQUENCE can have zero or -- constructs in this module. A valid ASN.1 SEQUENCE can have zero or
-- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to -- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
-- have at least one entry. MAX indicates the upper bound is unspecified. -- have at least one entry. MAX indicates the upper bound is unspecified.
-- Implementations are free to choose an upper bound that suits their -- Implementations are free to choose an upper bound that suits their
-- environment. -- environment.
skipping to change at line 2113 skipping to change at line 2117
contentType ContentType, contentType ContentType,
signedContentIdentifier ContentIdentifier, signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING } originatorSignatureValue OCTET STRING }
id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-ct-receipt OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-ct(1) 1}
-- Section 2.9 -- Section 2.9
ContentHints ::= SEQUENCE { ContentHints ::= SEQUENCE {
contentDescription UTF8String SIZE (1..MAX) OPTIONAL,   contentDescription UTF8String SIZE (1..MAX) OPTIONAL,
contentType ContentType }   contentType ContentType }
id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-aa-contentHint OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4} rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 4}
-- Section 2.10 -- Section 2.10
MsgSigDigest ::= OCTET STRING MsgSigDigest ::= OCTET STRING
id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-aa-msgSigDigest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5} us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 5}
skipping to change at line 2160 skipping to change at line 2164
unmarked (0), unmarked (0),
unclassified (1), unclassified (1),
restricted (2), restricted (2),
confidential (3), confidential (3),
secret (4), secret (4),
top-secret (5) } (0..ub-integer-options) top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256 ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE { ESSPrivacyMark ::= CHOICE {
pString PrintableString SIZE (1..ub-privacy-mark-length),     pString      PrintableString SIZE (1..ub-privacy-mark-length),
utf8String UTF8String SIZE (1..MAX)     utf8String   UTF8String SIZE (1..MAX)
} }
ub-privacy-mark-length INTEGER ::= 128 ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory SecurityCategory
ub-security-categories INTEGER ::= 64 ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE { SecurityCategory ::= SEQUENCE {
skipping to change at line 2222 skipping to change at line 2226
EntityIdentifier ::= CHOICE { EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber, issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier } subjectKeyIdentifier SubjectKeyIdentifier }
MLReceiptPolicy ::= CHOICE { MLReceiptPolicy ::= CHOICE {
none [0] NULL, none [0] NULL,
insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames, insteadOf [1] SEQUENCE SIZE (1..MAX) OF GeneralNames,
inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames } inAdditionTo [2] SEQUENCE SIZE (1..MAX) OF GeneralNames }
-- Section 5.4
SigningCertificate ::= SEQUENCE {
certs SEQUENCE OF ESSCertID,
policies SEQUENCE OF PolicyInformation OPTIONAL
}
id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) <TBD> }
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
END -- of ExtendedSecurityServices END -- of ExtendedSecurityServices
B. References B. References
[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax [ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
Notation One (ASN.1)" Notation One (ASN.1)"
[ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax [ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
Notation One (ASN.1)" Notation One (ASN.1)"
skipping to change at line 2272 skipping to change at line 2299
Bancroft Scott Bancroft Scott
Bengt Ackzell Bengt Ackzell
Blake Ramsdell Blake Ramsdell
Carlisle Adams Carlisle Adams
David Kemp David Kemp
Jim Schaad Jim Schaad
Russ Housley Russ Housley
Scott Hollenbeck Scott Hollenbeck
Steve Dusse Steve Dusse
D. Open Issues D. Changes from draft-ietf-smime-ess-08 to draft-ietf-smime-ess-09
None.
E. Changes from draft-ietf-smime-ess-07 to draft-ietf-smime-ess-08
3.4.2: Tiny typos.
4.4: Added ASN.1 for EntityIdentifier. Also added this to Appendix A.
5: Added this entire section. 5: Many small changes from John Pawling. See
<http://www.imc.org/ietf-smime/mail-archive/2206.html>. Also changed
CertID to ESSCertID.
A: Removed EntityIdentifier from the imports from CMS, and added A: Copied the new ASN.1 from 5 (whoops!). Put in an import of
IssuerAndSerialNumber to the imports. PolicyInformation from PKIX, and an import of CertificateSerialNumber from
the CertificateExtensions module.
F. Editor's Address E. Editor's Address
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 Santa Cruz, CA 95060
(831) 426-9827 (831) 426-9827
phoffman@imc.org phoffman@imc.org
 End of changes. 

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