Tim,
These are your first steps as Security Area Advisor of the S/MIME WG
and as Security Area Director.
See my comments below.
Denis,
The unaddressed Last Call comments noted by Russ were actually IETF
Last Call comments from the Gen-ART document review team.
As I understand it, your comments were submitted during working group
deliberations, but working group consensus was *not* demonstrated.
When there are two people expressing their views: one saying YES and one saying
NO,
is it possible to speak of a consensus ?
Anyway, the IETF last call level is also there to address issues that could not
be solved
at the WG level.
I send a copy of this message to Sam Hartman, your Security Area Director
co-chair,
so that you can discuss this issue together.
In addition, this document was explicitly scoped to address algorithm
agility for the esscertid structure. The changes you propose are
focused on an unrelated issue - name uniqueness. I understand that
name uniqueness is a hot button issue for you, but it is out of scope
for this particular document.
The key issue is about the following sentence which is wrong:
"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) ."
There are two solutions to solve this issue:
1) correct the sentence (and I have made a proposal for it); or
2) delete the sentence (fall-back solution).
Please consider these two options.
Organizations (including ETSI) are starting to specify this structure
in other documents. We have an urgent need to complete this document
so they have a stable reference, and I do not want to hold up the
train for unrelated issues.
I am indeed well placed to know that we (at ETSI) need this document to go out.
Thanks for your understanding.
Denis
I have asked Jim Schaad to address the
gen-ART comments before I forward this document to the IESG, but I
will not impose the same conditions for your comments.
Thanks for your understanding.
Tim Polk
On Apr 17, 2007, at 10:06 AM, Denis Pinkas wrote:
Jim,
draft-ietf-smime-escertid-04.txt is currently on hold, since the
Security Area Director (Russ) said :
« Several Last Call comments were received that deserve a response.
The author has not answered them yet. It is clear that a revised I-
D will be needed. »
This document needs to be progressed.
Three issues need to be solved:
1) In November 2006, I asked changes for the following paragraph:
The issuer/serial number pair is the method of identification of
certificates used in [PKIXCERT]. That document imposes a
restriction
for certificates that the issuer distinguished name must be
present.
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. 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.
I now propose the following:
That document imposes a restriction for certificates that the
issuer distinguished name (DN) must be present. If certificate
issuers had unique names, then the issuer/serial number pair would
be sufficient to uniquely identify the correct signing certificate.
However the uniqueness of the DN of a certificate issuer cannot be
guaranteed, hence two certificate issuers might use the same DN,
either without knowing it or intentionally. The issuer name
contained in the issuer/serial number pair should thus only be used
as an hint to identify a certificate issuer.
In the case where the issuer/serial number pair is not used in the
sid, it SHOULD be placed in the issuerSerial field of the
ESSCertIDv2 structure.
2) I asked to switch the second and the third paragraph of section
(5.4.1.1)
since it is more logical to say that one information provides a hint,
while the second provides assurance that the certificate is the
right one.
Hereafter is a full text replacement:
That document imposes a restriction for certificates that the
issuer distinguished name (DN) must be present. If certificate
issuers had unique names, then the issuer/serial number pair would
be sufficient to uniquely identify the correct signing certificate.
However the uniqueness of the DN of a certificate issuer cannot be
guaranteed, hence two certificate issuers might use the same DN,
either without knowing it or intentionally. The issuer name
contained in the issuer/serial number pair should thus only be used
as an hint to identify a certificate issuer.
In the case where the issuer/serial number pair is not used in the
sid, it SHOULD be placed in the issuerSerial field of the
ESSCertIDv2 structure.
The hash of the entire certificate allows for a verifier to check
that the certificate used in the verification process was the same
certificate the signer intended. Hashes are convenient in that
they
are frequently used by certificate stores as a method of
indexing and
retrieving certificates as well. 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.
3) The definition of serialNumber is not fully adequate since it takes
the view of the issuer (?for the issuer?). It would be more
appropriate
to take the view from the relying party.
The current definition is:
serialNumber holds the serial number that uniquely identifies the
certificate for the issuer.
The following definition is proposed instead:
serialNumber holds a serial number that is unique for each
certificate issued by a given CA.
Denis
Regards,
Denis Pinkas