circumstances where the signer may wish to limit the set of
certificates that may be used in verifying a signature. It is useful
to be able to list the set of certificates the signer wants the
recipient to use in validating the signature.
5.3.2 Policy Information
A related aspect of the certificate binding is the issue of multiple
certification paths. In some instances, the semantics of a
certificate in its use with a message may depend on the Certificate
Authorities and policies that apply. To address this issue, the
signer may also wish to 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 the policy ID is described here.
5.4 Signing Certificate Attribute Definition
The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set
of authorization certificates to be used in verifying a signature.
The definition of SigningCertificate is
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) 12 }
The first certificate identified in the sequence of certificate
identifiers MUST be the certificate used to verify the signature. The
encoding of the ESSCertID for this certificate SHOULD include the
issuerSerial field. If other constraints ensure that
issuerAndSerialNumber will be present in the SignerInfo, the
issuerSerial field MAY be omitted. The certificate identified is used
during the signature verification process. If the hash of the
certificate does not match the certificate used to verify the
signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of
ESSCertIDs, the certificates after the first one limit the set of
authorization certificates that are used during signature validation.
Authorization certificates can be either attribute certificates or
normal certificates. The issuerSerial field (in the ESSCertID
structure) SHOULD be present for these certificates, unless the
client who is validating the signature is expected to have easy
access to all the certificates requred for validation. If only the
signing certificate is present in the sequence, there are no
restrictions on the set of authorization certificates used in
validating the signature.
The sequence of policy information terms identifies those certificate
policies that the signer asserts apply to the certificate, and under
which the certificate should be relied upon. This value suggests a
policy value to be used in the relying party's certification path
validation.
If present, the SigningCertificate attribute MUST be a signed
attribute; it MUST NOT be an unsigned attribute. CMS defines
SignedAttributes as a SET OF Attribute. A SignerInfo MUST NOT include
multiple instances of the SigningCertificate attribute. CMS defines
the ASN.1 syntax for the signed attributes to include attrValues SET
OF AttributeValue. A SigningCertificate attribute MUST include only a
single instance of AttributeValue. There MUST NOT be zero or multiple
instances of AttributeValue present in the attrValues SET OF
AttributeValue.
5.4.1 Certificate Identification
The best way to identify certificates is an often-discussed issue.
[CERT] has imposed a restriction for SignedData objects that the
issuer DN must be present in all signing certificates. The
issuer/serial number pair is therefore sufficient to identify the
correct signing certificate. This information is already present, as
part of the SignerInfo object, and duplication of this information
would be unfortunate. A hash of the entire certificate serves the
same function (allowing the receiver to verify that the same
certificate is being used as when the message was signed), is
smaller, and permits a detection of the simple substitution attacks.
Attribute certificates and additional public key certificates
containing authorization information do not have an issuer/serial
number pair represented anywhere in a SignerInfo object. When an
attribute certificate or an additional public key certificate is not
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. For this reason, these certificates SHOULD be identified
by the IssuerSerial object.
This document defines a certificate identifier as:
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
When creating an ESSCertID, the certHash is computed over the entire
DER encoded certificate including the signature. The issuerSerial
would normally be present unless the value can be inferred from other
information.
When encoding IssuerSerial, serialNumber is the serial number that
uniquely identifies the certificate. For non-attribute certificates,
the issuer MUST contain only the issuer name from the certificate
encoded in the directoryName choice of GeneralNames. For attribute
certificates, the issuer MUST contain the issuer name field from the
attribute certificate.
6. Security Considerations
All security considerations from [CMS] and [SMIME3] apply to
applications that use procedures described in this document.
As stated in Section 2.3, a recipient of a receipt request must not
send back a reply if it cannot validate the signature. Similarly, if
there conflicting receipt requests in a message, the recipient must
not send back receipts, since an attacker may have inserted the
conflicting request. Sending a signed receipt to an unvalidated
sender can expose information about the recipient that it may not
want to expose to unknown senders.
Senders of receipts should consider encrypting the receipts to
prevent a passive attacker from gleaning information in the receipts.
Senders must not rely on recipients' processing software to correctly
process security labels. That is, the sender cannot assume that
adding a security label to a message will prevent recipients from
viewing messages the sender doesn't want them to view. It is expected
that there will be many S/MIME clients that will not understand
security labels but will still display a labelled message to a
recipient.
A receiving agent that processes security labels must handle the
content of the messages carefully. If the agent decides not to show
the message to the intended recipient after processing the security
label, the agent must take care that the recipient does not
accidentally see the content at a later time. For example, if an
error response sent to the originator contains the content that was
hidden from the recipient, and that error response bounces back to
the sender due to addressing errors, the original recipient can
possibly see the content since it is unlikely that the bounce message
will have the proper security labels.
A man-in-the-middle attack can cause a recipient to send receipts to
an attacker if that attacker has a signature that can be validated by
the recipient. The attack consists of intercepting the original
message and adding a mLData attribute that says that a receipt should
be sent to the attacker in addition to whoever else was going to get
the receipt.
Mailing lists that encrypt their content may be targets for denial-
of-service attacks if they do not use the mailing list management
described in Section 4. Using simple RFC822 header spoofing, it is
quite easy to subscribe one encrypted mailing list to another,
thereby setting up an infinite loop.
Mailing List Agents need to be aware that they can be used as oracles
for the the adaptive chosen ciphertext attack described in [CMS].
MLAs should notify an administrator if a large number of
undecryptable messages are received.
When verifying a signature using certificates that come with a [CMS]
message, the recipient should only verify using certificates
previously known to be valid, or certificates that have come from a
signed SigningCertificate attribute. Otherwise, the attacks described
in Section 5 can cause the receiver to possibly think a signature is
valid when it is not.
A. ASN.1 Module
ExtendedSecurityServices
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0) ess(2) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
-- Cryptographic Message Syntax (CMS)
ContentType, IssuerAndSerialNumber, SubjectKeyIdentifier
FROM CryptographicMessageSyntax { iso(1) member-body(2) us(840)
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
GeneralNames, CertificateSerialNumber FROM CertificateExtensions
{joint-iso-ccitt ds(5) module(1) certificateExtensions(26) 0};
-- Extended Security Services
-- 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
-- more entries. The SIZE (1..MAX) construct constrains the SEQUENCE to
-- have at least one entry. MAX indicates the upper bound is unspecified.
-- Implementations are free to choose an upper bound that suits their
-- environment.
UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
-- The contents are formatted as described in [UTF8]
-- Section 2.7
ReceiptRequest ::= SEQUENCE {
signedContentIdentifier ContentIdentifier,
receiptsFrom ReceiptsFrom,
receiptsTo SEQUENCE SIZE (1..ub-receiptsTo) OF GeneralNames }
ub-receiptsTo INTEGER ::= 16
id-aa-receiptRequest OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 1}
ContentIdentifier ::= OCTET STRING
id-aa-contentIdentifier OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 7}
ReceiptsFrom ::= CHOICE {
allOrFirstTier [0] AllOrFirstTier,
-- formerly "allOrNone [0]AllOrNone"
receiptList [1] SEQUENCE OF GeneralNames }
AllOrFirstTier ::= INTEGER { -- Formerly AllOrNone
allReceipts (0),
firstTierRecipients (1) }
-- Section 2.8
Receipt ::= SEQUENCE {
version ESSVersion,
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
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}
ESSVersion ::= INTEGER { v1(1) }
-- Section 2.9
ContentHints ::= SEQUENCE {
contentDescription UTF8String (SIZE (1..MAX)) OPTIONAL,
contentType ContentType }
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}
-- Section 2.10
MsgSigDigest ::= OCTET STRING
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}
-- Section 2.11
ContentReference ::= SEQUENCE {
contentType ContentType,
signedContentIdentifier ContentIdentifier,
originatorSignatureValue OCTET STRING }
id-aa-contentReference OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 10 }
-- Section 3.2
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
id-aa-securityLabel OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 2}
SecurityPolicyIdentifier ::= OBJECT IDENTIFIER
SecurityClassification ::= INTEGER {
unmarked (0),
unclassified (1),
restricted (2),
confidential (3),
secret (4),
top-secret (5) } (0..ub-integer-options)
ub-integer-options INTEGER ::= 256
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String UTF8String (SIZE (1..MAX))
}
ub-privacy-mark-length INTEGER ::= 128
SecurityCategories ::= SET SIZE (1..ub-security-categories) OF
SecurityCategory
ub-security-categories INTEGER ::= 64
SecurityCategory ::= SEQUENCE {
type [0] OBJECT IDENTIFIER,
value [1] ANY DEFINED BY type -- defined by type
}
--Note: The aforementioned SecurityCategory syntax produces identical
--hex encodings as the following SecurityCategory syntax that is
--documented in the X.411 specification:
--
--SecurityCategory ::= SEQUENCE {
-- type [0] SECURITY-CATEGORY,
-- value [1] ANY DEFINED BY type }
--
--SECURITY-CATEGORY MACRO ::=
--BEGIN
--TYPE NOTATION ::= type | empty
--VALUE NOTATION ::= value (VALUE OBJECT IDENTIFIER)
--END
-- Section 3.4
EquivalentLabels ::= SEQUENCE OF ESSSecurityLabel
id-aa-equivalentLabels OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 9}
-- Section 4.4
MLExpansionHistory ::= SEQUENCE
SIZE (1..ub-ml-expansion-history) OF MLData
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}
ub-ml-expansion-history INTEGER ::= 64
MLData ::= SEQUENCE {
mailListIdentifier EntityIdentifier,
expansionTime GeneralizedTime,
mlReceiptPolicy MLReceiptPolicy OPTIONAL }
EntityIdentifier ::= CHOICE {
issuerAndSerialNumber IssuerAndSerialNumber,
subjectKeyIdentifier SubjectKeyIdentifier }
MLReceiptPolicy ::= CHOICE {
none [0] NULL,
insteadOf [1] 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) 12 }
ESSCertID ::= SEQUENCE {
certHash Hash,
issuerSerial IssuerSerial OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
IssuerSerial ::= SEQUENCE {
issuer GeneralNames,
serialNumber CertificateSerialNumber
}
END -- of ExtendedSecurityServices
B. References
[ASN1-1988] "Recommendation X.208: Specification of Abstract Syntax
Notation One (ASN.1)".
[ASN1-1994] "Recommendation X.680: Specification of Abstract Syntax
Notation One (ASN.1)".
[CERT] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
Handling", RFC2632, June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC2630,
June 1999.
[MSG] Ramsdell, B., Editor, "S/MIME Version 3 Message
Specification", RFC2633, June 1999.
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[MSP4] "Secure Data Network System (SDNS) Message Security
Protocol (MSP) 4.0", Specification SDN.701, Revision A,
1997-02-06.
[MTSABS] "1988 International Telecommunication Union (ITU) Data
Communication Networks Message Handling Systems: Message
Transfer System: Abstract Service Definition and
Procedures, Volume VIII, Fascicle VIII.7, Recommendation
X.411"; MTSAbstractService {joint-iso-ccitt mhs-motis(6)
mts(3) modules(0) mts-abstract-service(1)}
[PKCS7-1.5] Kaliski, B., "PKCS #7: Cryptographic Message Syntax",
RFC2315, March 1998.
[SMIME2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
L. Repka"S/MIME Version 2 Message Specification", RFC
2311, March 1998, and Dusse, S., Hoffman, P. and B.
Ramsdell,"S/MIME Version 2 Certificate Handling", RFC
2312, March 1998.
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC2279, January 1998.
C. Acknowledgments
The first draft of this work was prepared by David Solo. John Pawling
did a huge amount of very detailed revision work during the many
phases of the document.
Many other people have contributed hard work to this memo, including:
Andrew Farrell
Bancroft Scott
Bengt Ackzell
Bill Flanigan
Blake Ramsdell
Carlisle Adams
Darren Harter
David Kemp
Denis Pinkas
Francois Rousseau
Jim Schaad
Russ Housley
Scott Hollenbeck
Steve Dusse
Editor's Address
Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060
EMail: phoffman@imc.org
Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.