Internet Draft Jim Schaad draft-ietf-smime-sigattr-00.txt Microsoft May 9, 1998 Expires in six months Signing Certificate Attribute Specification Status of this memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract A set of attacks on SignedData objects have been identified relating to the fact that the certificate to be used when verifying the signature in a SignerInfo is not cryptographically bound into the signature. This leads to a set of attacks where the certificate used to verify the signature is altered leading to possible incorrect results. This document describes these attacks and provides ways to deal with some of the attacks. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to > with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . 1. Introduction Concerns have been raised over the fact that the certificate which the signer of a [CMS] SignedData object desired to be bound into the verification process of the SignedData object is not cryptographically bound into the signature itself. This draft attempts to address this issue by creating a new attribute to be placed in the signedAttributes or authenticated attributes section of a SignerInfo object. This document presents a description of a set of possible attacks dealing with the substitution of one certificate to verify the signature for the desired certificate. A set of ways for preventing or addressing these attacks is presented to deal with the simplest of the attacks. 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 I have identified 3 different attacks that can be launched against a possible signature verification process by changing the certificate(s) used in the signature verification process. Substitution Attack The first attack deals with simple substitution of one certificate for another certificate. In this attack the issuer and serial number in the SignerInfo is modified to refer to a new certificate. This new certificate is used the signature verification process. The first version of this attack is a simple denial of service attack where an invalid certificate is substituted for the valid certificate. This renders the message unverifiable, as the public key in the certificate no longer matches the private key used to sign the message The second version is a substitution of one valid certificate for the original valid certificate where the public keys in the certificates match. This allows for the signature to be validated under potentially different certificate constraints than the originator of the message used Reissue of Certificate The second attack deals with a Certificate Authority re- issuing the signing certificate (or potentially one of its certificates). This attack may start becoming more frequent as Certificate Authorities re-issue there own root certificates and change policies in the certificate while doing so. When a certificate is re-issued using different policies (or extensions), the validation code 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 The third attack deals with a rogue entity setting up a certificate authority that attempts to duplicate the structure of an existing Certificate Authority. Specifically, the rogue entity issues a new certificate with the same public keys as the signer used, but signed by the rogue entity's private key. 3. Attack Responses This document does not attempt to solve all of the above attacks, however a brief description of responses to each of the attacks is given in this section. Substitution Attack The denial of service attack cannot be prevented, once the certificate identifier has been modified in transit no verification of the signature is possible. There is no way to automatically identify the attack either, it is indistinguishable from a message corruption. The substitution of a valid certificate can be responded to in two different manners. The first is to make a blanket statement that the use of the same public key in two different certificates is bad practice and should be avoided. In practice there is no practical way to prevent users from doing this and we need to assume that they will. Section 4 provides a new attribute to be included in the SignerInfo signed attributes. This binds the correct certificate identifier into the signature. This will convert the attack from a potentially successful one to a denial of service attack. Reissue of Certificate A Certificate Authority should never reissue a certificate with different attributes. Certificate Authorities that do so are following incorrect practices and cannot be relied on. Addition of a hash of the complete signing certificate (including signature value) to the 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 substantial change the attribute presented in section 4. The only way to prevent this from occuring is to 1) have the sequence of issuer/serial numbers with the hash of each certificate be included and 2) prevent the use of cross certificates in validating the leaf certificate. Except in closed PKIs (where this should not be a problem anyway) the problems associated with not using cross certificates make solving this problem unacceptable. Rogue Duplicate Certificate Authority The best method of preventing this attack is to avoid trusting the rogue certificate authority. The addition of the hash to the attribute defined in section 4 can prevent the use of end-entity certificates from the rogue authority, however the only true way to prevent this attack is to never trust the rough CA. 4. Signing Certificate Attribute The signing certificate attribute is designed to prevent the second version of the substitution attack and verify that the correct certificate is being used in the signature certificate validation process. The following object identifier identifies the signingCertificate attribute type: id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) } The definition of SigningCertificate is SigningCertificate ::= IssuerAndSerialNumber When this attribute is present in the set of signed attributes of a SignerInfo structure, the issuer DN and serial number of the certificate providing the public key used in verifying the signature on the message is to be compared to the values in this attribute. If the issuer DN and serial number do not match, the signature is considered to be invalid. A. ASN.1 Module To be supplied. B. Open Issues There is considerable feeling among a portion of the community that more information needs to be placed in the 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 of Certificate" attack. I see no pressing need to address this attack. Any certificate authority that allowed for this attack is operating in an improper fashion and should not be used. In the event that the attack is deemed to be of importance, it could be solved by the addition of a 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 complete chain to be specified in the SigningCertificate attribute. This would address the "Rogue Duplicate 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 private/public key is the basis of a signature and an attribute such as is proposed here is anathema. My personal feeling on this issue is that while this is true from a cryptographic sense, it is not true from a protocol sense. In a signing protocol the certificate associated with the signature is a vital portion of the signature verification process. One cannot use any certificate that comes to hand which will cryptographically verify the signature. References CMS "Cryptographic Message Syntax", Internet Draft ietf- draft-smime-cms MUSTSHOULD "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119 Security Considerations To be supplied, but will include: Must keep a complete copy or equivalent of the certificate in the trusted root database, issuer serial number is insufficient. Private key material must be protected. Authors Address Jim Schaad Microsoft One Microsoft Way Redmond, WA 98052-6399 jimsch@microsoft.com