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

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 23 Apr 2007 14:34:59 +0200

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