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

From: Blake Ramsdell <[email-masked]>
Date: Mon, 27 Nov 2006 20:00:21 -0800

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

---

From: "Denis Pinkas"<[email-masked]>
Date: Tue, 28 Nov 2006 15:41:26 +0100

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 ! 

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

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

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 
      } 

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. 

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.   

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. 

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.   

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. 

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.  

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. 

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

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. 

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. 

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 

Blake

---

From: Russ Housley <[email-masked]>
Date: Tue, 28 Nov 2006 12:10:38 -0500

[ Changing the Subject to match the document being discussed. ]

>    serialNumber  holds the serial number of the certificate.

The serial number must be unique for the CA (not universally 
unique).  I think adding some words to clarify this would be better 
than dropping words.

Russ