Subject: draft-ietf-smime-escertid-04.txt

From: "Denis Pinkas" <[email-masked]>
Date: Tue, 17 Apr 2007 16:06:38 +0200

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

---

From: Tim Polk <[email-masked]>
Date: Fri, 20 Apr 2007 14:07:37 -0400

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