Subject: Re: [pkix] WGLC on draft-ietf-pkix-rfc5280-clarifications-00.txt

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 01 Jul 2010 13:10:40 +0200

I think I should add, I can perfectly understand there can be good 
reasons why it's too late and this change is not important enough to add 
now.

But I don't want to just read it's all the fault of implementers who 
don't read the proper RFC and that the text is perfect as it is.

It's the purpose of standards to be precise enough to avoid the pitfalls 
in which implementers easily falls, and they do fall into that one.

Jean-Marc Desperrier wrote:
> Sorry, I missed this mail during the last days.
>
> Well the problem Stefan is that *they are not implementers of TLS* !
>
> They see themselves just as people who create certificates that will be
> used in a TLS context but they will not implement any bit of that, so
> *do* *not* believe they need to read the full TLS reference.
>
> Second, there is something wrong with the current text.
>
> It gives information, but that information is incomplete.
>
> So it gives X509 implementers a false sense of knowing enough to emit a
> TLS certificate. That's about as bad as including incorrect information.
>
> You are right that adding a reference is probably not enough, it would
> certainly be much better to remove the current text and put the
> reference instead of it.
>
> Stefan Santesson wrote:
>> Implementers of TLS should read the TLS spec.
>>
>> Even though I would not mind if the reference had been there from the
>> beginning I'm not sure this should be included in the current draft.
>> Technically there is nothing wrong with the current text.
>>
>> Those who ignores applicable standards and makes false implementations
>> will
>> probably not stop doing so just because we add a reference in this update
>> document.
>>
>> Thus I would agree with David.
>>
>> /Stefan
>>
>>
>> On 10-06-17 4:11 PM, "Jean-Marc Desperrier"<[email-masked]> wrote:
>>
>>> David A. Cooper wrote:
>>>> I don't see a problem with adding a brief reference to Section 7.4.2 of
>>>> RFC 5246 for additional information about TLS server certificates,
>>>> or to
>>>> Section 7.4.6 of RFC 5246 for additional information about TLS client
>>>> certificates, or to RFC 2560 for additional information about when the
>>>> id-kp-OCSPSigning OID needs to appear in certificates.
>>>>
>>>> However, Tim Polk has said
>>>> (http://www.ietf.org/mail-archive/web/pkix/current/msg27247.html) that
>>>> editorial changes are outside of the limited scope of
>>>> draft-ietf-pkix-rfc5280-clarifications.
>>>
>>> That would be an editorial change ? It only modifies a comment in the
>>> definition of the structure.
>>>
>>> And RFC 5246 allows the same digitalSignature, keyEncipherment or
>>> keyAgreement bits as the current text, it just provides better
>>> explanation about when to choose which one.
>>>
>>> I'm OK with just adding the reference to RFC 5246 and keeping the
>>> current text to avoid suspicions of editorial change.
>>> _______________________________________________
>>> pkix mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/pkix
>>
>>
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix