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

From: "Pope, Nick" <[email-masked]>
Date: Mon, 29 Oct 2007 13:54:31 -0000

All,

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

Nick

> -----Original Message-----
> From: Turner, Sean P. [mailto:[email-masked]]
> Sent: 19 October 2007 21:00
> To: 'Julien Stern'; [email-masked]
> 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).
> 
> 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,
> >
> >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).
> >
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
2NX.
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 [email-masked].
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".