Internet Draft                                               Jim Schaad
draft-ietf-smime-sigattr-00.txt
draft-ietf-smime-sigattr-01                                   Microsoft
May 9,
July 2, 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.

  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 learn the entire list of current Internet-Drafts, status of any Internet-Draft, 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), nic.nordu.net (Europe),
  munnari.oz.au (Pacific Rim), ftp.ietf.org ds.internic.net (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' "ietf-smime" mailing list.  To
  join the list, send a message to <ietf-smime-
 request@imc.org <mailto:request@imc.org> > <ietf-smime-request@imc.org> with the
  single word
 'subscribe' "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 addresses 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.

  Attribute certificates can be used as part of a signature verification
  process.  As [CMS] currently stands there is no way to include the
  list of attribute certificates to be used in the verification process.
  The set of attribute certificates used in the signature verification
  process needs to have the ability for the signer to restrict the set
  of certificates.  This information needs to be encoded in a manner
  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

  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 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 re-issuing the
  signing certificate (or potentially one of its certificates).  This
  attack may start becoming more frequent as Certificate Authorities re-issue 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  This problem also occurs when cross
  certificates in validating a certificate
 path can lead to similar problems. When the cross
 certificate is (with potentially different restrictions) are 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.
  process of verifying a signature.

  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 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  Using the hash
  of the complete signing certificate (including	signature value) as the reference to the
 signingCertificate attribute defined in section 4 would
 identify certificate prevents this attack
  attach for the end-entity certificate. At
 the present time I do not feel	this attack needs to be
 prevented. certificates.

  Preventing the	re-issuing attack based on reissuing of CA certificates requires would
  require a substantial change the attribute presented in section 4.
 The only way to prevent this from occuring is to 1) have
 the 5.  It
  would require that a sequence of issuer/serial numbers with the	hash of
 each certificate identifiers 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 attribute.  This presents problem
 anyway) under the problems associated with not circumstances where
  the relying party is using a cross
 certificates certificate as part of its
  authentication process and this certificate does not appear on the
  list of certificates.  The problems outside of a closed PKI make solving the
  addition of this	problem	unacceptable. information prone to error causing the rejection of
  valid chains.

  Rogue Duplicate Certificate Authority

  The best method of preventing this attack is to avoid trusting the
  rogue certificate authority.  The addition use of the hash to the attribute defined in section 4	can prevent identify
  certificates prevents 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 Certificates

  Attribute certificates are required to prevent
 the second version do validation of the substitution	attack and verify signatures for
  some applications.  This requires that the correct certificate is being used in the
 signature certificate validation process.

 The following object identifier identifies application be able to find
  the
 signingCertificate correct 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 certificates to perform the verification process
  and there is

 SigningCertificate ::=	IssuerAndSerialNumber

 When this currently no list of attribute is	present certificates in a
  SignerInfo object.  The sender has the ability to include a set of signed
 attributes of
  attribute certificates in a SignerInfo structure, SignedData object.  The receiver has the issuer DN and
 serial	number of
  ability to retrieve attribute certificates from a directory service.
  There are some circumstances where the certificate providing signer may wish to limit the	public key
  set of attribute certificates that may be used in verifying the signature on the	message	is a
  signature.  It would be useful to be
 compared able to list the set of attribute
  certificates the values signer wants used in validating the signature.

  Given that this	attribute. If attribute is dealing with the issuer
 DN and	serial number do not match, certificate used in
  verifying the signature is
 considered to be invalid.

A. ASN.1 Module

 To be supplied.

B. Open	Issues

 There is considerable feeling among on a portion of the
 community SignerInfo object, it makes sense that	more information needs to be placed in it
  should also address the
 SigningCertificate ASN	structure. I don't currently see a
 need for this for issue of limiting the following reason: The identification set of a certificate currently used in CMS attribute
  certificates as well.

5.   Certificate Identification

  The best way to identify certificates is an often discussed issued.
  [CMS] has imposed a restriction for SignedData objects that the issuer and
 serial	number pair. The main purpose of this attribute	at
  DN must be present in all signing certificates.  The issuer/serial
  number pair is therefore sufficient to authenticate this information and thus this
 is identify the	only correct signing
  certificate.  This information that is duplicated.

 Some people have expressed a desire to	solve already present, as part of the "Reissue
  SignerInfo object, and duplication of Certificate" attack. I see no pressing need	to address this attack. Any information would be
  unfortunate.  A hash of the entire certificate serves the same
  function (allowing the receiver to very the same certificate authority	that allowed for
 this attack is	operating in an	improper fashion being
  used), is smaller and should
 not be	used. In permits a detection of the event that simple substitution
  attacks.

  Attribute certificates do not have an issuer/serial number pair
  represented anywhere in a SignerInfo object.  When the attack certificate is deemed to	be
 of importance,
  not included in the SignedData object, it could be solved by becomes much more difficult
  to get the addition correct set of certificates based only on a hash to of the SigningCertificate	ASN structure.
  certificate.  For this reasons attribute certificates are identified
  by the issuer/serial number pair.

  This would
 allow 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 relying entity to verify that certHash is computed over the entire DER
  encoded certificate
 was exactly including the same as signature.  The
  issuerAndSerialNumber would normally be present unless the value can
  be inferred from other information.

6.   Signing Certificate Attribute

  The signing entity claimed certificate attribute is designed to have
 used.

 There was a desired expressed at one point prevent the simple
  substitution and re-issue attacks and to allow for a
 complete chain restricted set of
  attribute certificates to be specified 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> }

  The definition of SigningCertificate
 attribute. is

       SigningCertificate ::=  SEQUENCE OF CertID

  The first certificate in the sequence of certificates MUST be the
  certificate used to verify the signature.  The encoding of the CertID
  for this certificate SHOULD NOT include the issuerAndSerialNumber.
  (The issuerAndSerialNumber is already present in the SignerInfo.) This would address
  certificate is used during the "Rogue Duplicate
 Certificate Authority"	attack.	I do signature verification process.  If the
  hash of the certificate does not think we should
 address this problem for match the following	reasons: 1. Nothing
 says that I will use certificate used to decode
  the exact	same path signature, the signature MUST be considered invalid.

  If more than one certificate is present in the sequence of CertIDs,
  the certificates
 to verify after the signature as what you "used" when producing first one limit the signature.	(An example set of this would attribute
  certificates that are used during signature validation.  The
  issuerAndSerialNumber SHOULD be present, unless the rollover
 of validator is
  expected to have easy access to all certificates required.  If only
  the	root signing certificate is present (a single item in the	signers	PKI.) 2. This
 adds size to sequence)
  there are no restrictions on the set of attribute without gaining appreciable
 benefits.

 There is 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 portion SET OF AuthAttribute.  A SignerInfo MUST
  NOT include multiple instances of the community that feels	that SigningCertificate attribute.
  CMS defines the
 private/public	key is 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 basis attrValues SET OF AttributeValue.

A.   ASN.1 Module

  SigningCertificate
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
         smime(16) modules(0) sca(?) }

  DEFINITIONS IMPLICIT TAGS ::=
  BEGIN

  EXPORTS
       SigningCertificate

  IMPORTS
      -- Cryptographic Message Syntax
          IssuerAndSerialNumber
          FROM CryptographicMessageSyntax { iso(1) member-body(2)
               us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
               modules(0) cms(1) };

  CertID ::=  SEQUENCE {
     certHash              Hash,
       issuerAndSerialNumber    IssuerAndSerialNumber OPTIONAL
  }

  Hash ::= OCTET STRING -- SHA1 hash of entire certificate

  SigningCertificate ::=  SEQUENCE OF CertID

  END

B.   Open Issues

  Should CertID be a signature CHOICE rather than a SEQUENCE?  This makes the
  encoded bytes smaller, but does mean that you can't have both the hash
  and an
 attribute such	as is proposed here is anathema. the issuer/serial number together.  My personal feeling on this issue feelings 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 ability to have both outweighs the signature is a vital portion small overhead of the signature
 verification process. One cannot use any certificate that
 comes sequence.

C.   Changes

  On request from Russ, I have added the ability to hand which will cryptographically verify refer to attribute
  certificates from this attribute.
  Allow for using hashes as well as issuer/serial number for referring
  to certificates.
  Added the
 signature. ASN module to Appendix A

References

  CMS       "Cryptographic Message Syntax", Internet Draft ietf-
 draft-smime-cms 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: supplied
       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

Author's Address

  Jim Schaad
  Microsoft
  One Microsoft Way
  Redmond, WA 98052-6399
 jimsch@microsoft.com 98XXX
  Jimsch@microsoft.com