Re: WG LAST CALL: draft-ietf-smime-cades-00.txt :flexibility of the ESSC

Flexibility of the ESSCertID field

 

This document (draft-ietf-smime-cades-00.txt) which is an update of RFC 3126

(Electronic Signature Formats for long term electronic signatures) has

identified the fact that there was the need to support ESSCertID with hash

functions different from SHA-1.

 

For this, the following attribute has been defined, but is most

probably not yet implemented.

 

5.7.3.2 Other signing certificate attribute definition

 

The following attribute is identical to the ESS signing-certificate

defined above except that this attribute can be used with hashing

algorithms other than SHA-1.

 

This attribute shall be used in the same manner as defined above

for the ESS signing-certificate attribute.

 

The following object identifier identifies the other-signing-

certificate attribute:

 

id-aa-ets-otherSigCert OBJECT IDENTIFIER ::= { iso(1)

    member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)

    smime(16) id-aa(2) 19 }

 

The other-signing-certificate attribute value has the ASN.1 syntax

OtherSigningCertificate:

 

OtherSigningCertificate ::=  SEQUENCE {

    certs        SEQUENCE OF OtherCertID,

    policies     SEQUENCE OF PolicyInformation OPTIONAL

                 -- NOT USED IN THE PRESENT DOCUMENT }

 

OtherCertID ::= SEQUENCE {

    otherCertHash            OtherHash,

    issuerSerial             IssuerSerial OPTIONAL }

 

OtherHash ::= CHOICE {

    sha1Hash OtherHashValue,  -- This contains a SHA-1 hash

    otherHash OtherHashAlgAndValue}

 

OtherHashValue ::= OCTET STRING

 

OtherHashAlgAndValue ::= SEQUENCE {

    HashAlgorithm     AlgorithmIdentifier,

    HashValue         OtherHashValue }

 

In RFC 2634 we currently have :

 

5.4 Signing Certificate Attribute Definition

 

   The signing certificate attribute is designed to prevent the simple

   substitution and re-issue attacks, and to allow for a restricted set

   of authorization certificates to be used in verifying a signature.

 

   The definition of SigningCertificate is

 

   SigningCertificate ::=  SEQUENCE {

       certs        SEQUENCE OF ESSCertID,

       policies     SEQUENCE OF PolicyInformation OPTIONAL

   }

 

   id-aa-signingCertificate OBJECT IDENTIFIER ::= { iso(1)

       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)

       smime(16) id-aa(2) 12 }

 

There has been some discussions on the list to reach the same goal with

a simpler syntax.

 

The goal is now to avoid have two different attributes (with different syntaxes)

that would have the same properties.

 

One proposal was:

 

   ESSCertIDv2 ::= SEQUENCE {

   certHash          Hash,

   issuerSerial      IssuerSerial OPTIONAL,

   hashAlgorithm [0] AlgorithmIdentifier DEFAULT {algorithm id-sha1}

}

 

while another proposal was:

 

   ESSCertIDv2 ::= SEQUENCE {

   hashAlgorithm  AlgorithmIdentifier DEFAULT {algorithm id-sha1}

   certHash       Hash,

   issuerSerial   IssuerSerial OPTIONAL

   }

 

Peter was in favor of the first one, while Russ was in favor of the

second one.

 

This could lead to the following new definition:

 

   SigningCertificate ::=  SEQUENCE {

       certs        SEQUENCE OF ESSCertIDv2,

       policies     SEQUENCE OF PolicyInformation OPTIONAL

   }

 

A solution would also be to adopt the attribute that is already defined

in RC 3126, but which is more complex.

 

ETSI could align the ETSI Technical Report (TR) than is equivalent to

this proposed RFC with the newly defined attribute, once an agreement

is reached on this list.

 

Any opinions ?

 

Denis

 

----owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org wrote: -----

To: ietf-smime(_at_)imc(_dot_)org
From: Blake Ramsdell <blake(_at_)sendmail(_dot_)com>
Sent by: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
Date: 01/09/2006 11:39AM
Subject: WG LAST CALL: draft-ietf-smime-cades-00.txt


This message initiates an SMIME Working Group Last Call on the document:

Title : CMS Advanced Electronic Signatures (CAdES)
> Author(s) : J. Ross, et al.
Filename : draft-ietf-smime-cades-00.txt
Pages : 132
> Date : 2005-12-2

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-00.txt

The purpose of this WG Last Call is to ensure that the Working Group
has achieved consensus that the document is suitable for publication
as an Informational RFC.

Please review the document for both technical and editorial problems.
Technical issues should be discussed on this list. Editorial issues
may be sent to the document editor.

The Last Call period will end on Monday, January 16, 2006.


Upon completion of the last call, the WG chairs will take action
based upon the consensus of the WG. Possible actions include:


1) recommending to the IETF Security Area Directors
that the document, after possible editorial or
other minor changes, be considered by the IESG
for publication as an Informational RFC
(which generally involves an IETF-wide Last Call); or


2) requiring that outstanding issues be adequately
addressed prior to further action (including,
possibly, another WG Last Call).


Remember that it is our responsibility as Working Group members to
ensure the quality of our documents and of the Internet Standards
process. So, please read and comment!

Blake
--
Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com