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