Subject: WG LAST CALL: draft-ietf-smime-cades-00.txt

From: Blake Ramsdell <[email-masked]>
Date: Mon, 9 Jan 2006 02:39:05 -0800

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

---

From: Kenji Urushima <[email-masked]>
Date: Tue, 24 Jan 2006 23:11:19 +0900

Hi all,

I have missed to comment before 
the end of the last call however
I'll rather comment to the draft.

1) Archive Timestamp attribute type OID issue
   (Section 6.4.1 Archive time-stamp attribute definition)

The archive hash calculation method was entirely changed
between RFC 3126 and CAdES I-D. As for archive timestamp attribute
itself we can't find which method was used.
So I think it would be better if other
OID is assigned to the attribute.

> id-aa-ets-archiveTimestamp OBJECT IDENTIFIER ::= { iso(1) member-
> body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 27}

2) Archive Hash Target Issue (6.4.1 Archive time-stamp attribute definition)

I think the archive hash method definition in this I-D and 
ETSI TS 101 733 v1.5.1 or later is ambiguous than RFC 3126.

2-1) encapContentInfo as archive hash target

the I-D definition is below:

> The value of messageImprint field within TimeStampToken shall be a hash 
> of the concatenation of:
> 
>   - The encapContentInfo element of the SignedData sequence;

As for CMS SignedData, a document to be signed may be included
in the 'attached signature' form or excluded in the 'detached signature'
form.
There is no description about those differences in the I-D.
I think a signing document should be add to archive hash targets
in order to archive long term integrity however
to encode attached format encapContentInfo for huge data
will be hard work. Also eContent of encapContentInfo may represented
indefinite length data of ASN.1 BER encoding.
(See `5.2.  EncapsulatedContentInfo Type' of RFC 3852)
It may better to add only signing data itself.

2-2) normalization of ASN.1 BER encoded data

A signedAttrs field of CMS SignedData should be
DER encoded as described in the CMS definition:

> RFC 3852 CMS '5.3.  SignerInfo Type'
>
>      signedAttrs is a collection of attributes that are signed.  The
>      field is optional, but it MUST be present if the content type of
>      the EncapsulatedContentInfo value being signed is not id-data.
>      SignedAttributes MUST be DER encoded, even if the rest of the
>      structure is BER encoded.  Useful attribute types, such as signing
>      time, are defined in Section 11.  If the field is present, it MUST
>      contain, at a minimum, the following two attributes:

I think other fields which are added to archive hash target should be
normalized to DER encoding since hash value results may vary for 
its encoding. I think the way of normalization for archive hash target
should
be described in the I-D.

3) Version 3 SignedData issue (5.4 SignedData type)

> The syntax of the SignedData of the ES is as defined in CMS (RFC 3852 
> [4]).
> 
> The fields of type SignedData have the meanings as defined in CMS (RFC 
> 3852 [4]) except that:
> 
>    - the syntax version number value shall be 3.

I'm afraid that a certificate without subjectKeyIdentifier extension
can not be used for CAdES in many cases.
Since if any attribute certificates will not included in the SignedData and
the signer's certificate has no subjectKeyIdentifier
X.509.v3 extension then it will be version 1 SignedData.
(See the definitions in RFC 3852 section 5.1 and 5.3)

What do you think?

Kenji

--
Kenji URUSHIMA | Entrust Japan | http://japan.entrust.com/