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