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

From: Stefan Santesson <[email-masked]>
Date: Tue, 08 Jun 2010 21:09:11 +0200

All,

Draft draft-ietf-pkix-rfc5280-clarifications-00.txt has been out as a pkix
draft since April and before that it has been circulated as an individual
submission.
Since the last edits which lead to the current draft, this document has not
received any further comment.

Work group last call is therefore initiated on this document.
Last call ends on June 25.

/Stefan

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 17 Jun 2010 10:48:34 +0200

On 08/06/2010 21:09, Stefan Santesson wrote:
> Draft draft-ietf-pkix-rfc5280-clarifications-00.txt has been out as a 
> pkix draft since April and before that it has been circulated as an 
> individual submission.
> Since the last edits which lead to the current draft, this document 
> has not received any further comment.
>
I wonder if those two changes in the draft are really the only useful 
clarifications RFC5280 needs.

That seems really few, I'm not convinced the period since the initial 
draft has been really effective to get all issues implementers often 
meet come out.
I feel the lack of reaction on this document should have meant some 
effort to get more returns before starting last call.

This being said :
I see at least one missing point, where an enhancement to the current 
text would be really useful.

4.2.1.12. Extended Key Usage

    id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
    -- TLS WWW server authentication
    -- Key usage bits that may be consistent: digitalSignature,
    -- keyEncipherment or keyAgreement

In practice, implementers read only this and put some random selection 
of  digitalSignature, keyEncipherment or keyAgreement in the 
certificate, not understanding the precise consequences their choice has.

What they need to know, what this document doesn't say, and *doesn't 
push them* to read the document that does give the adequate instructions :
- keyAgreement will only make sense if the public key of your cert is a 
Diffie-Hellman key. It's the only bit you need then.
- digitalSignature is required (and sufficient) for Ephemeral 
Diffie-Hellman based key exchange. EDH is the only way to get forward 
secrecy. EDH can be used with most types of server public keys (RSA, DSA 
and ECDSA).
- keyEncipherment is required (and sufficient) for standard key exchange 
with server that have a RSA key (and if you don't require forward 
secrecy, so don't want to use an EDH based key exchange instead).

The current text doesn't get the proper result, because implementers 
trie to work with *only* the insufficient info it contains.
The text for the other EKU is similarly imprecise, but the proper EKU to 
use are more intuitive, so I don't see a strong need for change there.

I believe the proper solution is *not* to copy in RFC5246 this detailled 
information about TLS.
This would be duplicate information which is never a good thing.

I think the proper solution is to replace this text by a reference to 
the adequate text in RFC5246 :

4.2.1.12. Extended Key Usage

    id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
    -- TLS WWW server authentication
    -- Paragraph 7.4.2 in [RFC5246] describes which key usage bits are
    -- consistent, according to the public key algorithm of the server
    -- and the cipher suite used

And then adding [RFC5246] to the list of references.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 17 Jun 2010 09:53:22 -0400

Jean-Marc,

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.

As I understand it, a new RFC that obsoletes RFC 5280 will be created as 
part of the process of advancing the certificate and CRL profile to the 
status of Draft Standard, and the time to address editorial issues such 
as the one you are proposing is during the development of that RFC.

Dave

On 06/17/2010 04:48 AM, Jean-Marc Desperrier wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
> .
>
>

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Thu, 17 Jun 2010 16:11:23 +0200

> 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.

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 23 Jun 2010 11:54:33 +0200

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

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Mon, 28 Jun 2010 20:19:56 +0200

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:
> On 10-06-17 4:11 PM, "Jean-Marc Desperrier"<[email-masked]>  wrote:
>
>> David A. Cooper wrote: