[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re:draft-ietf-smime-escertid-04.txt
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