Subject: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic Signatures (CAdES)) to Informational RFC

From: The IESG <[email-masked]>
Date: Thu, 18 Oct 2007 17:20:46 -0400

The IESG has received a request from the S/MIME Mail Security WG (smime)
to consider the following document:

- 'CMS Advanced Electronic Signatures (CAdES) '
   <draft-ietf-smime-cades-06.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-11-01. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-smime-cades-06.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14070&rfc_flag=0

---

From: "Kenji Urushima" <[email-masked]>
Date: Fri, 19 Oct 2007 06:58:41 +0900

Hi,

There is an erratum in the I-D.

=== [Page52]
=== 6.3.6 Time-stamped certificates and crls references attribute 
=== definition 

****
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) memberus(840) 
rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26}
****

This should be following.

****
id-aa-ets-certCRLTimestamp OBJECT IDENTIFIER ::= { iso(1) member-body(2)

us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 26}
****

Regards,

- Kenji

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

---

From: "Julien Stern" <[email-masked]>
Date: Fri, 19 Oct 2007 09:54:15 +0200

Hi,

the RFC contains the same issues as the corresponding ETSI standard.
These issue will most likely by fixed in a revision of the standard,
but they are currently present.

If the RFC is supposed to be strictly aligned with version 1.7.3
of ETSI 101 733, and if a new version revision of the RFC is planned
when the new revision of the ETSI standard occurs, then dismiss these
comments.

Regards,

--
Julien

----------------------
In section 6.2.1:

QUOTE:
| The complete-certificate-references attribute is an unsigned attribute.
| It references the full set of CA certificates ...

There can (and SHOULD in fact) be some other certificates
(CRL Issuers, OCSP responders, ...)

----------------------
In section 6.2.2:

This section calls for a one-to-one mapping from the revocation
information on the certificates and talks about certificate path.

QUOTE:
| CompleteRevocationRefs shall contain one CrlOcspRef for the signing-
| certificate, followed by one for each OtherCertID in the 
| CompleteCertificateRefs attribute.  The second and subsequent 
| CrlOcspRef fields shall be in the same order as the OtherCertID to 
| which they relate.  
| At least one of CRLListID or OcspListID or OtherRevRefs should be present
| for all but the "trusted" CA of the certificate path.

The certificate "path" is not a "path". It is a "tree" in the
general case. This makes the one-to-one mapping more complex to
implement. This may force the duplication of references. And finally,
it is not possible to always respect the latest rules (e.g. for an
OCSP responder with the no-check extension).

---

From: "Turner, Sean P." <[email-masked]>
Date: Fri, 19 Oct 2007 15:59:52 -0400

My understanding is that this ID is technically equivalent to ETSI TS 101
733 V.1.7.3 (according to the abstract).

spt 

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Julien Stern
>Sent: Friday, October 19, 2007 3:54 AM
>To: [email-masked]
>Subject: Re: Last Call: draft-ietf-smime-cades (CMS Advanced 
>Electronic Signatures (CAdES)) to Informational RFC
>
>
>Hi,
>
>These issue will most likely by fixed in a revision of the 
>standard, but they are currently present.
>
>If the RFC is supposed to be strictly aligned with version 
>1.7.3 of ETSI 101 733, and if a new version revision of the 
>RFC is planned when the new revision of the ETSI standard 
>occurs, then dismiss these comments.
>
>Regards,
>
>--
>Julien
>
>----------------------
>In section 6.2.1:
>
>QUOTE:
>There can (and SHOULD in fact) be some other certificates (CRL 
>Issuers, OCSP responders, ...)
>
>
>----------------------
>In section 6.2.2:
>
>This section calls for a one-to-one mapping from the 
>revocation information on the certificates and talks about 
>certificate path.
>
>QUOTE:
>| At least one of CRLListID or OcspListID or OtherRevRefs should be 
>| present for all but the "trusted" CA of the certificate path.
>
>general case. This makes the one-to-one mapping more complex 
>to implement. This may force the duplication of references. 
>And finally, it is not possible to always respect the latest 
>rules (e.g. for an OCSP responder with the no-check extension).
>