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