draft-ietf-smime-escertid-02.txt   draft-ietf-smime-escertid-03.txt 
Network Working Group J. Schaad Network Working Group J. Schaad
Internet-Draft Soaring Hawk Consulting Internet-Draft Soaring Hawk Consulting
Intended status: Informational December 21, 2006
Expires: October 3, 2006 Expires: June 24, 2007
ESS Update: Adding CertID Algorithm Agility ESS Update: Adding CertID Algorithm Agility
draft-ietf-smime-escertid-02.txt draft-ietf-smime-escertid-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2006. This Internet-Draft will expire on June 24, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
In the original Enhanced Security Services for S/MIME draft, a In the original Enhanced Security Services for S/MIME draft, a
structure for cryptographically linking the certificate to be used in structure for cryptographically linking the certificate to be used in
validation with the signature was introduced, this structure was validation with the signature was introduced, this structure was
skipping to change at page 4, line 22 skipping to change at page 4, line 22
design. The only substantial difference between the two attributes design. The only substantial difference between the two attributes
is that SigningCertificateV2 allows for hash algorithm agility, while is that SigningCertificateV2 allows for hash algorithm agility, while
SigningCertificate forces the use of the SHA-1 hash algorithm. With SigningCertificate forces the use of the SHA-1 hash algorithm. With
the recent advances in the ability to create hash collisions for the recent advances in the ability to create hash collisions for
SHA-1 it is deemed wise to move forward sooner rather than later. SHA-1 it is deemed wise to move forward sooner rather than later.
When the SHA-1 hash function is used, the SigningCertificate When the SHA-1 hash function is used, the SigningCertificate
attribute MUST be used. The SigningCertificateV2 attribute MUST be attribute MUST be used. The SigningCertificateV2 attribute MUST be
used if any algorithm other than SHA-1 is used and SHOULD NOT be used used if any algorithm other than SHA-1 is used and SHOULD NOT be used
for SHA-1. Applications SHOULD recognize both attributes as long as for SHA-1. Applications SHOULD recognize both attributes as long as
they consider SHA-1 able to distingusih between two different they consider SHA-1 able to distinguish between two different
certificates. (I.e. the possiblity of a collision is suffiently certificates. (I.e. the possibility of a collision is sufficently
low.) low.)
Four cases exist which need to be taken into account when using this
attribute for correct processing:
1. Signature Validates and the hashes match: This is the success
case.
2. Signature Validates and the hashes do not match: In this case the
certificate contained the correct public key, the certificate
containing the public key is not the one that the signer intended
to be used. In this case the application should attempt a search
for a different certificate with the same public key and for
which the hashes match. If no such certificate can be found,
this is a failure case.
3. Signature Fails Validation and the hashes match: In this case it
can be assumed that the signature has been modified in some
fashion. This is a failure case.
4. Signature Fails Validation and the Hashes do not match: In this
case it can be either that the signature has been modified, or
that the wrong certificate has been used. Applications should
attempt a search for a different certificate which matches the
hash value in the attribute and use the new certificate to retry
the signature validation.
3. Insert new section 5.4.1 'Signing Certificate Attribute Definition 3. Insert new section 5.4.1 'Signing Certificate Attribute Definition
Version 2' Version 2'
5.4.1 Signing Certificate Attribute Definition Version 2 5.4.1 Signing Certificate Attribute Definition Version 2
The signing certificate attribute is designed to prevent the simple The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set substitution and re-issue attacks, and to allow for a restricted set
of authorization certificates to be used in verifying a signature. of authorization certificates to be used in verifying a signature.
SigningCertificateV2 is identified by the OID: SigningCertificateV2 is identified by the OID:
id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 47 }
The attribute has the ASN.1 definition: The attribute has the ASN.1 definition:
SigningCertificateV2 ::= SEQUENCE { SigningCertificateV2 ::= SEQUENCE {
certs SEQUENCE OF ESSCertIDv2, certs SEQUENCE OF ESSCertIDv2,
policies SEQUENCE OF PolicyInformation OPTIONAL policies SEQUENCE OF PolicyInformation OPTIONAL
} }
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)
smime(16) id-aa(2) 47 }
certs contains the list of certificates that are to be used in certs contains the list of certificates that are to be used in
validating the message. The first certificate identified in the validating the message. The first certificate identified in the
sequence of certificate identifiers MUST be the certificate used sequence of certificate identifiers MUST be the certificate used
to verify the signature. The encoding of the ESSCertIDv2 for this to verify the signature. The encoding of the ESSCertIDv2 for this
certificate SHOULD include the issuerSerial field. If other certificate SHOULD include the issuerSerial field. If other
constraints ensure that issuerAndSerialNumber will be present in constraints ensure that issuerAndSerialNumber will be present in
the SignerInfo, the issuerSerial field MAY be omitted. The the SignerInfo, the issuerSerial field MAY be omitted. The
certificate identified is used during the signature verification certificate identified is used during the signature verification
process. If the hash of the certificate does not match the process. If the hash of the certificate does not match the
certificate used to verify the signature, the signature MUST be certificate used to verify the signature, the signature MUST be
skipping to change at page 7, line 17 skipping to change at page 7, line 17
Insert the following text as a new section Insert the following text as a new section
5.4.1.1 Certificate Identification Version 2 5.4.1.1 Certificate Identification Version 2
The best way to identify certificates is an often-discussed issue. The best way to identify certificates is an often-discussed issue.
The ESSCertIDV2 structure supplies two different fields that are used The ESSCertIDV2 structure supplies two different fields that are used
for this purpose. for this purpose.
The hash of the entire certificate allows for a verifier to check The hash of the entire certificate allows for a verifier to check
that the certificate used in the verification process was the same that the certificate used in the verification process was the same
certificate the signer intended. Hashes are convient in that they certificate the signer intended. Hashes are convenient in that they
are frequently used by certificate stores as a method of indexing and are frequently used by certificate stores as a method of indexing and
retrieving certificates as well. The use of the hash is required by retrieving certificates as well. The use of the hash is required by
this structure since the detection of substitued certificates is this structure since the detection of substituted certificates is
based on the fact they would map to different hash values. based on the fact they would map to different hash values.
The issuer/serial number pair is the method of identification of The issuer/serial number pair is the method of identification of
certificates used in [PKIXCERT]. That document imposes a restriction certificates used in [PKIXCERT]. That document imposes a restriction
for certificates that the issuer DN must be present. The issuer/ for certificates that the issuer distinguished name must be present.
serial number pair would therefore normally be sufficient to identify The issuer/serial number pair would therefore normally be sufficient
the correct signing certificate. (This assumes the same issuer name to identify the correct signing certificate. (This assumes the same
is not re-used from the set of trust anchors.) The issuer/serial issuer name is not re-used from the set of trust anchors.) The
number pair can be stored in the sid field of the SignerInfo object. issuer/serial number pair can be stored in the sid field of the
However the sid field is not covered by the signature. In the cases SignerInfo object. However the sid field is not covered by the
where the issuer/serial number pair is not used in the sid or the signature. In the cases where the issuer/serial number pair is not
issuer/serial number pair needs to be signed, they SHOULD be placed used in the sid or the issuer/serial number pair needs to be signed,
in the issuerSerial field of the ESSCertIDv2 structure. it SHOULD be placed in the issuerSerial field of the ESSCertIDv2
structure.
Attribute certificates and additional public key certificates Attribute certificates and additional public key certificates
containing authorization information do not have an issuer/serial containing authorization information do not have an issuer/serial
number pair represented anywhere in a SignerInfo object. When an number pair represented anywhere in a SignerInfo object. When an
attribute certificate or an additional public key certificate is not attribute certificate or an additional public key certificate is not
included in the SignedData object, it becomes much more difficult to included in the SignedData object, it becomes much more difficult to
get the correct set of certificates based only on a hash of the get the correct set of certificates based only on a hash of the
certificate. For this reason, these certificates SHOULD be certificate. For this reason, these certificates SHOULD be
identified by the IssuerSerial object. identified by the IssuerSerial object.
skipping to change at page 8, line 28 skipping to change at page 8, line 28
The fields of ESSCertIDv2 are defined as follows: The fields of ESSCertIDv2 are defined as follows:
hashAlg contains the identifier of the algorithm used in computing hashAlg contains the identifier of the algorithm used in computing
certHash. certHash.
certHash is computed over the entire DER encoded certificate certHash is computed over the entire DER encoded certificate
including the signature. including the signature.
issuerSerial holds the identification of the certificate. The issuerSerial holds the identification of the certificate. The
issuerSerial would normally be present unless the value can be issuerSerial would normally be present unless the value can be
inferred from other information. inferred from other information (e.g. the sid field of the
SignerInfo object).
The fields of IssuerSerial are defined as follows: The fields of IssuerSerial are defined as follows:
issuer contains the issuer name of the certificate. For non- issuer contains the issuer name of the certificate. For non-
attribute certificates, the issuer MUST contain only the issuer attribute certificates, the issuer MUST contain only the issuer
name from the certificate encoded in the directoryName choice of name from the certificate encoded in the directoryName choice of
GeneralNames. For attribute certificates, the issuer MUST contain GeneralNames. For attribute certificates, the issuer MUST contain
the issuer name field from the attribute certificate. the issuer name field from the attribute certificate.
serialNumber holds the serial number that uniquely identifies the serialNumber holds the serial number that uniquely identifies the
certificate. certificate for the issuer CA.
5. Insert new section 5.4.2 ' Signing Certificate Attribute Defintion 5. Insert new section 5.4.2 ' Signing Certificate Attribute Defintion
Version 1 Version 1
5.4.2 Signing Certificate Attribute Definition Version 1 5.4.2 Signing Certificate Attribute Definition Version 1
The signing certificate attribute is designed to prevent the simple The signing certificate attribute is designed to prevent the simple
substitution and re-issue attacks, and to allow for a restricted set substitution and re-issue attacks, and to allow for a restricted set
of authorization certificates to be used in verifying a signature. of authorization certificates to be used in verifying a signature.
 End of changes. 12 change blocks. 
22 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/