draft-ietf-smime-sigattr-00.txt   draft-ietf-smime-sigattr-01.txt 
Internet Draft Jim Schaad Internet Draft Jim Schaad
draft-ietf-smime-sigattr-00.txt Microsoft draft-ietf-smime-sigattr-01 Microsoft
May 9, 1998 July 2, 1998
Expires in six months Expires in six months
Signing Certificate Attribute Specification Signing Certificate Attribute Specification
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are This document is an Internet-Draft. Internet-Drafts are working
working documents of the Internet Engineering Task Force documents of the Internet Engineering Task Force (IETF), its areas,
(IETF), its areas, and its working groups. Note that other and its working groups. Note that other groups may also distribute
groups may also distribute working documents as Internet- working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of Internet-Drafts are draft documents valid for a maximum of six months
six months and may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by other documents at any
other documents at any time. It is inappropriate to use time. It is inappropriate to use Internet-Drafts as reference material
Internet-Drafts as reference material or to cite them or to cite them other than as "work in progress."
other than as "work in progress."
To view the entire list of current Internet-Drafts, please check To learn the current status of any Internet-Draft, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu ftp.isi.edu (US West Coast).
(US West Coast).
Abstract Abstract
A set of attacks on SignedData objects have been A set of attacks on SignedData objects have been identified relating
identified relating to the fact that the certificate to be to the fact that the certificate to be used when verifying the
used when verifying the signature in a SignerInfo is not signature in a SignerInfo is not cryptographically bound into the
cryptographically bound into the signature. This leads to signature. This leads to a set of attacks where the certificate used
a set of attacks where the certificate used to verify the to verify the signature is altered leading to possible incorrect
signature is altered leading to possible incorrect results. This document describes these attacks and provides ways to
results. This document describes these attacks and deal with some of the attacks.
provides ways to deal with some of the attacks.
This draft is being discussed on the 'ietf-smime' mailing This draft is being discussed on the "ietf-smime" mailing list. To
list. To join the list, send a message to <ietf-smime- join the list, send a message to <ietf-smime-request@imc.org> with the
request@imc.org <mailto:request@imc.org> > with the single word single word "subscribe" in the body of the message. Also, there is a
'subscribe' in the body of the message. Also, there is a Web site Web site for the mailing list at <http://www.imc.org/ietf-smime>.
for the mailing list at <http://www.imc.org/ietf-smime>.
1. Introduction 1. Introduction
Concerns have been raised over the fact that the Concerns have been raised over the fact that the certificate which the
certificate which the signer of a [CMS] SignedData object signer of a [CMS] SignedData object desired to be bound into the
desired to be bound into the verification process of the verification process of the SignedData object is not cryptographically
SignedData object is not cryptographically bound into the bound into the signature itself. This draft addresses this issue by
signature itself. This draft attempts to address this creating a new attribute to be placed in the signedAttributes or
issue by creating a new attribute to be placed in the authenticated attributes section of a SignerInfo object.
signedAttributes or authenticated attributes section of a
SignerInfo object.
This document presents a description of a set of possible This document presents a description of a set of possible attacks
attacks dealing with the substitution of one certificate dealing with the substitution of one certificate to verify the
to verify the signature for the desired certificate. A signature for the desired certificate. A set of ways for preventing
set of ways for preventing or addressing these attacks is or addressing these attacks is presented to deal with the simplest of
presented to deal with the simplest of the attacks. the attacks.
Throughout this draft, the terms MUST, MUST NOT, SHOULD, Attribute certificates can be used as part of a signature verification
and SHOULD NOT are used in capital letters. This conforms process. As [CMS] currently stands there is no way to include the
to the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines list of attribute certificates to be used in the verification process.
the use of these key words to help make the intent of The set of attribute certificates used in the signature verification
standards track documents as clear as possible. The same process needs to have the ability for the signer to restrict the set
key words are used in this document to help implementers of certificates. This information needs to be encoded in a manner
achieve interoperability. that is covered by the signature on the SignedData object. This
document allows for the set of attribute certificates to be listed as
part of the signing certificate attribute.
Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD
NOT are used in capital letters. This conforms to the definitions in
[MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help
make the intent of standards track documents as clear as possible. The
same key words are used in this document to help implementers achieve
interoperability.
2. Attack Descriptions 2. Attack Descriptions
I have identified 3 different attacks that can be launched I have identified 3 different attacks that can be launched against a
against a possible signature verification process by possible signature verification process by changing the certificate(s)
changing the certificate(s) used in the signature used in the signature verification process.
verification process.
Substitution Attack Substitution Attack
The first attack deals with simple substitution of one The first attack deals with simple substitution of one certificate for
certificate for another certificate. In this attack the another certificate. In this attack, the issuer and serial number in
issuer and serial number in the SignerInfo is modified to the SignerInfo is modified to refer to a new certificate. This new
refer to a new certificate. This new certificate is used certificate is used the signature verification process.
the signature verification process.
The first version of this attack is a simple denial of The first version of this attack is a simple denial of service attack
service attack where an invalid certificate is substituted where an invalid certificate is substituted for the valid certificate.
for the valid certificate. This renders the message This renders the message unverifiable, as the public key in the
unverifiable, as the public key in the certificate no 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 The second version is a substitution of one valid certificate for the
certificate for the original valid certificate where the original valid certificate where the public keys in the certificates
public keys in the certificates match. This allows for match. This allows the signature to be validated under potentially
the signature to be validated under potentially different different certificate constraints than the originator of the message
certificate constraints than the originator of the message
used used
Reissue of Certificate Reissue of Certificate
The second attack deals with a Certificate Authority re- The second attack deals with a Certificate Authority re-issuing the
issuing the signing certificate (or potentially one of its signing certificate (or potentially one of its certificates). This
certificates). This attack may start becoming more attack may start becoming more frequent as Certificate Authorities re-
frequent as Certificate Authorities re-issue there own issue there own root certificates and change policies in the
root certificates and change policies in the certificate certificate while doing so. This problem also occurs when cross
while doing so. When a certificate is re-issued using certificates (with potentially different restrictions) are used in the
different policies (or extensions), the validation code process of verifying a signature.
may do different things based on the different policies
(or extensions).
The use of cross certificates in validating a certificate
path can lead to similar problems. When the cross
certificate is used in the validation code and the cross
certificate has different and non-equivalent policies and
extensions to the original certificate, the validation
code lead to different results based on whether the
original or the cross certificate is used. This problem
cannot be solved an requires due diligence be followed
when issuing cross certificates.
Rogue Duplicate Certificate Authority Rogue Duplicate Certificate Authority
The third attack deals with a rogue entity setting up a The third attack deals with a rogue entity setting up a certificate
certificate authority that attempts to duplicate the authority that attempts to duplicate the structure of an existing
structure of an existing Certificate Authority. Certificate Authority. Specifically, the rogue entity issues a new
Specifically, the rogue entity issues a new certificate certificate with the same public keys as the signer used, but signed
with the same public keys as the signer used, but signed
by the rogue entity's private key. by the rogue entity's private key.
3. Attack Responses 3. Attack Responses
This document does not attempt to solve all of the above This document does not attempt to solve all of the above attacks,
attacks, however a brief description of responses to each however a brief description of responses to each of the attacks is
of the attacks is given in this section. given in this section.
Substitution Attack Substitution Attack
The denial of service attack cannot be prevented, once the The denial of service attack cannot be prevented, once the certificate
certificate identifier has been modified in transit no identifier has been modified in transit no verification of the
verification of the signature is possible. There is no signature is possible. There is no way to automatically identify the
way to automatically identify the attack either, it is attack either, it is indistinguishable from a message corruption.
indistinguishable from a message corruption.
The substitution of a valid certificate can be responded The substitution of a valid certificate can be responded to in two
to in two different manners. The first is to make a different manners. The first is to make a blanket statement that the
blanket statement that the use of the same public key in use of the same public key in two different certificates is bad
two different certificates is bad practice and should be practice and should be avoided. In practice, there is no practical
avoided. In practice there is no practical way to prevent way to prevent users from doing this and we need to assume that they
users from doing this and we need to assume that they will. Section 4 provides a new attribute to be included in the
will. Section 4 provides a new attribute to be included SignerInfo signed attributes. This binds the correct certificate
in the SignerInfo signed attributes. This binds the identifier into the signature. This will convert the attack from a
correct certificate identifier into the signature. This potentially successful one to a denial of service attack.
will convert the attack from a potentially successful one
to a denial of service attack.
Reissue of Certificate Reissue of Certificate
A Certificate Authority should never reissue a certificate A Certificate Authority should never reissue a certificate with
with different attributes. Certificate Authorities that different attributes. Certificate Authorities that do so are
do so are following incorrect practices and cannot be following incorrect practices and cannot be relied on. Using the hash
relied on. Addition of a hash of the complete signing of the certificate as the reference to the certificate prevents this
certificate (including signature value) to the attach for end-entity certificates.
signingCertificate attribute defined in section 4 would
identify this attack for the end-entity certificate. At
the present time I do not feel this attack needs to be
prevented.
Preventing the re-issuing of CA certificates requires a Preventing the attack based on reissuing of CA certificates would
substantial change the attribute presented in section 4. require a substantial change the attribute presented in section 5. It
The only way to prevent this from occuring is to 1) have would require that a sequence of certificate identifiers be included
the sequence of issuer/serial numbers with the hash of in the attribute. This presents problem under the circumstances where
each certificate be included and 2) prevent the use of the relying party is using a cross certificate as part of its
cross certificates in validating the leaf certificate. authentication process and this certificate does not appear on the
Except in closed PKIs (where this should not be a problem list of certificates. The problems outside of a closed PKI make the
anyway) the problems associated with not using cross addition of this information prone to error causing the rejection of
certificates make solving this problem unacceptable. valid chains.
Rogue Duplicate Certificate Authority Rogue Duplicate Certificate Authority
The best method of preventing this attack is to avoid The best method of preventing this attack is to avoid trusting the
trusting the rogue certificate authority. The addition of rogue certificate authority. The use of the hash to identify
the hash to the attribute defined in section 4 can prevent certificates prevents the use of end-entity certificates from the
the use of end-entity certificates from the rogue rogue authority, however the only true way to prevent this attack is
authority, however the only true way to prevent this to never trust the rough CA.
attack is to never trust the rough CA.
4. Signing Certificate Attribute 4. Attribute Certificates
The signing certificate attribute is designed to prevent Attribute certificates are required to do validation of signatures for
the second version of the substitution attack and verify some applications. This requires that the application be able to find
that the correct certificate is being used in the the correct attribute certificates to perform the verification process
signature certificate validation process. and there is currently no list of attribute certificates in a
SignerInfo object. The sender has the ability to include a set of
attribute certificates in a SignedData object. The receiver has the
ability to retrieve attribute certificates from a directory service.
There are some circumstances where the signer may wish to limit the
set of attribute certificates that may be used in verifying a
signature. It would be useful to be able to list the set of attribute
certificates the signer wants used in validating the signature.
The following object identifier identifies the Given that this attribute is dealing with the certificate used in
signingCertificate attribute type: verifying the signature on a SignerInfo object, it makes sense that it
should also address the issue of limiting the set of attribute
certificates as well.
id-aa-signingCertificate OBJECT IDENTIFIER ::= { 5. Certificate Identification
iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) The best way to identify certificates is an often discussed issued.
pkcs9(9) [CMS] 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 very the same certificate is being
used), is smaller and permits a detection of the simple substitution
attacks.
Attribute certificates do not have an issuer/serial number pair
represented anywhere in a SignerInfo object. When the 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 reasons attribute certificates are identified
by the issuer/serial number pair.
This document defines a certificate identifier as:
CertID ::= SEQUENCE {
certHash Hash,
issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL
}
Hash ::= OCTET STRING -- SHA1 hash of entire certificate
When creating a CertID, the certHash is computed over the entire DER
encoded certificate including the signature. The
issuerAndSerialNumber would normally be present unless the value can
be inferred from other information.
6. Signing Certificate Attribute
The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks and to allow for a restricted set of
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> } smime(16) id-aa(2) <TBD> }
The definition of SigningCertificate is The definition of SigningCertificate is
SigningCertificate ::= IssuerAndSerialNumber SigningCertificate ::= SEQUENCE OF CertID
When this attribute is present in the set of signed The first certificate in the sequence of certificates MUST be the
attributes of a SignerInfo structure, the issuer DN and certificate used to verify the signature. The encoding of the CertID
serial number of the certificate providing the public key for this certificate SHOULD NOT include the issuerAndSerialNumber.
used in verifying the signature on the message is to be (The issuerAndSerialNumber is already present in the SignerInfo.) This
compared to the values in this attribute. If the issuer certificate is used during the signature verification process. If the
DN and serial number do not match, the signature is hash of the certificate does not match the certificate used to decode
considered to be invalid. the signature, the signature MUST be considered invalid.
If more than one certificate is present in the sequence of CertIDs,
the certificates after the first one limit the set of attribute
certificates that are used during signature validation. The
issuerAndSerialNumber SHOULD be present, unless the validator is
expected to have easy access to all certificates required. If only
the signing certificate is present (a single item in the sequence)
there are no restrictions on the set of attribute certificates used in
validating the signature.
If present, the SigningCertificate attribute MUST be an authenticated
attribute; it MUST NOT be an unauthenticated attribute. CMS defines
authenticatedAttributes as a SET OF AuthAttribute. A SignerInfo MUST
NOT include multiple instances of the SigningCertificate attribute.
CMS defines the ASN.1 syntax for the authenticated attributes to
include attrValues SET OF AttributeValue. A SigningCertificate
attribute MUST only include a single instance of AttributeValue.
There MUST NOT be zero or multiple instances of AttributeValue present
in the attrValues SET OF AttributeValue.
A. ASN.1 Module A. ASN.1 Module
To be supplied. SigningCertificate
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) modules(0) sca(?) }
B. Open Issues DEFINITIONS IMPLICIT TAGS ::=
BEGIN
There is considerable feeling among a portion of the EXPORTS
community that more information needs to be placed in the SigningCertificate
SigningCertificate ASN structure. I don't currently see a
need for this for the following reason: The identification
of a certificate currently used in CMS is the issuer and
serial number pair. The main purpose of this attribute at
present is to authenticate this information and thus this
is the only information that is duplicated.
Some people have expressed a desire to solve the "Reissue IMPORTS
of Certificate" attack. I see no pressing need to address -- Cryptographic Message Syntax
this attack. Any certificate authority that allowed for IssuerAndSerialNumber
this attack is operating in an improper fashion and should FROM CryptographicMessageSyntax { iso(1) member-body(2)
not be used. In the event that the attack is deemed to be us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
of importance, it could be solved by the addition of a modules(0) cms(1) };
hash to the SigningCertificate ASN structure. This would
allow the relying entity to verify that the certificate
was exactly the same as the signing entity claimed to have
used.
There was a desired expressed at one point to allow for a CertID ::= SEQUENCE {
complete chain to be specified in the SigningCertificate certHash Hash,
attribute. This would address the "Rogue Duplicate issuerAndSerialNumber IssuerAndSerialNumber OPTIONAL
Certificate Authority" attack. I do not think we should }
address this problem for the following reasons: 1. Nothing
says that I will use the exact same path of certificates
to verify the signature as what you "used" when producing
the signature. (An example of this would be the rollover
of the root certificate in the signers PKI.) 2. This
adds size to the attribute without gaining appreciable
benefits.
There is a portion of the community that feels that the Hash ::= OCTET STRING -- SHA1 hash of entire certificate
private/public key is the basis of a signature and an
attribute such as is proposed here is anathema. My SigningCertificate ::= SEQUENCE OF CertID
personal feeling on this issue is that while this is true
from a cryptographic sense, it is not true from a protocol END
sense. In a signing protocol the certificate associated
with the signature is a vital portion of the signature B. Open Issues
verification process. One cannot use any certificate that
comes to hand which will cryptographically verify the Should CertID be a CHOICE rather than a SEQUENCE? This makes the
signature. encoded bytes smaller, but does mean that you can't have both the hash
and the issuer/serial number together. My personal feelings is that
the ability to have both outweighs the small overhead of the sequence.
C. Changes
On request from Russ, I have added the ability to refer to attribute
certificates from this attribute.
Allow for using hashes as well as issuer/serial number for referring
to certificates.
Added the ASN module to Appendix A
References References
CMS "Cryptographic Message Syntax", Internet Draft ietf- CMS "Cryptographic Message Syntax", Internet Draft ietf-draft-
draft-smime-cms smime-cms
MUSTSHOULD "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119 MUSTSHOULD "Key words for use in RFCs to Indicate Requirement Levels",
RFC 2119
Security Considerations Security Considerations
To be supplied, but will include: To be supplied
Must keep a complete copy or equivalent of the Must keep a complete copy or equivalent of the certificate in the
certificate in the trusted root database, issuer serial trusted root database, issuer serial number is insufficient.
number is insufficient.
Private key material must be protected. Private key material must be protected.
Authors Address Author's Address
Jim Schaad Jim Schaad
Microsoft Microsoft
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98XXX
jimsch@microsoft.com Jimsch@microsoft.com
 End of changes. 

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