[Top] [All Lists]

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

2007-10-19 13:26:33

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


-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org 
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Julien 
Sent: Friday, October 19, 2007 3:54 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Last Call: draft-ietf-smime-cades (CMS Advanced 
Electronic Signatures (CAdES)) to Informational RFC


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.



In section 6.2.1:

| The complete-certificate-references attribute is an unsigned 
| 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.

| 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).

<Prev in Thread] Current Thread [Next in Thread>