[Top] [All Lists]

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

2007-10-29 07:37:50


I can confirm this (apologies for the slow response - I have been away).


-----Original Message-----
From: Turner, Sean P. [mailto:turners(_at_)ieca(_dot_)com]
Sent: 19 October 2007 21:00
To: 'Julien Stern'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic
Signatures (CAdES)) to Informational RFC

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

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email 
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

<Prev in Thread] Current Thread [Next in Thread>
  • RE: Last Call: draft-ietf-smime-cades (CMS Advanced Electronic Si gnatures (CAdES)) to Informational RFC, Pope, Nick <=