Subject: RE: WG LAST CALL: draft-ietf-smime-cms-mult-sign-02.txt

From: "Jim Schaad" <[email-masked]>
Date: Fri, 1 Dec 2006 15:17:32 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Tuesday, November 28, 2006 6:41 AM
> To: ietf-smime
> Subject: Re: WG LAST CALL: draft-ietf-smime-cms-mult-sign-02.txt
> 
> 
> You will find hereafter, 14 comments on 
> draft-ietf-smime-escertid-02.txt
>  
> 1. Editorial. The draft states: « Expires: October 3, 2006”.  
>  The document is expired ! 
Done

> 
> 2. Editorial. The issue date is: April 2006. This date is incorrect. 
Done

> 
> 3. Editorial. Page 3. Section 2. Third paragraph. There are 
> four typos. 
> 
> Change :  
>           Applications SHOULD recognize both attributes as long as   
>          they consider SHA-1 able to distingusih between two different
>          certificates.  (I.e. the possiblity of a collision 
> is suffiently   
>          low.) 
> 
> into: 
>           Applications SHOULD recognize both attributes as long as 
>    they consider SHA-1 able to distinguish between two different 
>    certificates.  (i.e. the possibility of a collision is 
> sufficiently 
>    low.) 

3 of 4 are done - I'll leave the fourth up to the copy editors to see if
they want to make.

> 
> 4. Editorial. Page 4. Section 3. 
> 
> The draft states: 
> 
>    SigningCertificateV2 is identified by the OID: 
>       id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 
> 
>    The attribute has the ASN.1 definition: 
> 
>       SigningCertificateV2 ::=  SEQUENCE { 
>           certs        SEQUENCE OF ESSCertIDv2, 
>           policies     SEQUENCE OF PolicyInformation OPTIONAL 
>       } 
> 
>           member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 
>           smime(16) id-aa(2) 47 } 
> 
> whereas it should state : 
> 
>    SigningCertificateV2 is identified by the OID: 
> 
>       id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= { iso(1) 
>          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 
>          smime(16) id-aa(2) 47 } 
> 
>    The attribute has the ASN.1 definition: 
> 
>       SigningCertificateV2 ::=  SEQUENCE { 
>           certs        SEQUENCE OF ESSCertIDv2, 
>           policies     SEQUENCE OF PolicyInformation OPTIONAL 
>       } 

Done

> 
> 5. Page 4. The text states:  
> 
>                                The first certificate 
> identified in the 
>       sequence of certificate identifiers MUST be the 
> certificate used 
>       to verify the signature. 
> 
> 
> whereas it should state : 
> 
>                             The first certificate identified in the 
>       sequence of certificate identifiers MUST be the certificate  
>       to be used to verify the signature. 
> 

Not done - I don't think this change adds any clarity to the document

> 
> 6. Editorial. Page 6. The text states:  
> 
> 
>                                        Hashes are convient in 
> that they 
>    are frequently used by certificate stores as a method of 
> indexing and 
>    retrieving certificates as well.   
> 
> whereas it should state : 
> 
>                                        Hashes are convenient 
> in that they 
>    are frequently used by certificate stores as a method of 
> indexing and 
>    retrieving certificates as well.   
> 
Done

> 
> 7. Editorial. Page 6. The text states:  
> 
> 
>                                   The use of the hash is required by 
>    this structure since the detection of substitued certificates is 
>    based on the fact they would map to different hash values. 
> 
> whereas it should state : 
> 
>                                   The use of the hash is required by 
>    this structure since the detection of substituted certificates is 
>    based on the fact they would map to different hash values. 

Done

> 
> 8. Page 6. The text states:  
> 
>    The issuer/serial number pair is the method of identification of 
>    certificates used in [PKIXCERT].   
> 
> whereas it should state : 
> 
>    The issuer/serial number pair is the information to be used to  
>    look for certificates used in [PKIXCERT] when they are not 
> a priori  
>    known.   

Not done - I don't see any additional clarity from this statement.

> 
> 9. Page 6. The text states:  
> 
>                                     That document imposes a 
> restriction 
>    for certificates that the issuer DN must be present. 
> 
> This sentence is not understandable and does not exist for 
> the version 1. 
> Please delete or explain. 

I don't understand what is not clear.  [PKIX] says that you must populate
the issuer DN field.  That is all this says.

> 
> 
> 10. Page 6. The text states:  
>                                                              
> The issuer/ 
>    serial number pair would therefore normally be sufficient 
> to identify 
>    the correct signing certificate.  (This assumes the same 
> issuer name 
>    is not re-used from the set of trust anchors.)  The issuer/serial 
>    number pair can be stored in the sid field of the 
> SignerInfo object. 
>    However the sid field is not covered by the signature.   
> 
> This text is not necessary and is misleading. It is also 
> quite strange to see that the text for v2 is very different 
> from the text for v1.  
> Nevertheless, since the next sentence is fully sufficient, 
> then it is proposed to suppress it.  

We have had several discussions on this, I am not planning to change this
text.

> 
> 11. Editorial. Page 6. Change “they” by “it”. The text states:  
> 
>                                                          In the cases 
>    where the issuer/serial number pair is not used in the sid or the 
>    issuer/serial number pair needs to be signed, they SHOULD 
> be placed 
>    in the issuerSerial field of the ESSCertIDv2 structure. 
> 
> whereas it should state : 
> 
>                                                          In the cases 
>    where the issuer/serial number pair is not used in the sid or the 
>    issuer/serial number pair needs to be signed, it SHOULD be placed 
>    in the issuerSerial field of the ESSCertIDv2 structure. 

Done

> 
> 12. Page 7. The text states:  
> 
>    issuerSerial  holds the identification of the certificate.  The 
>       issuerSerial would normally be present unless the value can be 
>       inferred from other information. 
> 
> It would be worth to add at the end of that sentence: 
>     (e.g. the sid field of the SignerInfo object). 

Done

> 
> 13. Page 7. The text states:  
> 
>    serialNumber  holds the serial number that uniquely identifies the 
>       certificate. 
> 
> This text is misleading since serial number does not always 
> allow to uniquely identify a certificate. Replace with: 
> 
>    serialNumber  holds the serial number of the certificate. 

I have added to the end of the sentence "for the issuer CA"
> 
> 14. Page 8. The text states:  
> 
>    The first certificate identified in the sequence of certificate 
>    identifiers MUST be the certificate used to verify the signature. 
> 
> Replace with: 
> 
>    The first certificate identified in the sequence of certificate 
>    identifiers MUST be the certificate to be used to verify 
> the signature. 

Not Done - I don't think this adds additional clarity to the sentence.
> 
> Denis 
> 
> 
> ---------
> De : owner-ietf-smime
> À : ietf-smime
> Date : 2006-11-28, 05:00:21
> Sujet : WG LAST CALL: draft-ietf-smime-cms-mult-sign-02.txt 
> 
> 
> This message initiates an SMIME Working Group Last Call on 
> the document: 
> 
>   Title : Cryptographic Message Syntax (CMS) Multiple Signer 
> Clarification
>   Author(s) : R. Housley
>   Filename : draft-ietf-smime-cms-mult-sign-02.txt
>   Pages : 5
>   Date : 2006-11-9 
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-mult-
> sign-02.txt 
> 
> The purpose of this WG Last Call is to ensure that the 
> Working Group has achieved consensus that the document is 
> suitable for publication as an Informational RFC. 
> 
> Please review the document for both technical and editorial 
> problems.  
> Technical issues should be discussed on this list. Editorial 
> issues may be sent to the document editor. 
> 
> The Last Call period will end on Monday, December 11, 2006. 
> 
> 
> Upon completion of the last call, the WG chairs will take 
> action based upon the consensus of the WG. Possible actions include: 
> 
> 
>     1) recommending to the IETF Security Area Directors 
>        that the document, after possible editorial or 
>        other minor changes, be considered by the IESG 
>        for publication as an Informational RFC 
>        (which generally involves an IETF-wide Last Call); or 
> 
> 
>     2) requiring that outstanding issues be adequately 
>        addressed prior to further action (including, 
>        possibly, another WG Last Call). 
> 
> 
> Remember that it is our responsibility as Working Group 
> members to ensure the quality of our documents and of the 
> Internet Standards process. So, please read and comment! 
> 
> Blake
> --
> Blake Ramsdell | Sendmail, Inc. | http://www.sendmail.com
> 
> 
>