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