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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Julien
Stern
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
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).