One document matched: draft-ietf-smime-sigattr-00.txt

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

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