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 <ietf-smime-
 request@imc.org <mailto:request@imc.org> > with the single word
 'subscribe' in the body of the message. Also, there is a Web site
 for the mailing list at <http://www.imc.org/ietf-smime>.

. 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.


. 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.

. 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.

. 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) <TBD> }

 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