Re: [Technical Errata Reported] RFC5280 (5802)

-----Original Message-----
From: pkix <[email protected]> On Behalf Of Martin Rex
Sent: Tuesday, August 6, 2019 2:22 PM
To: Russ Housley <[email protected]>
Cc: Roman D. Danyliw <[email protected]>; Ben Kaduk <[email protected]>; IETF PKIX
<[email protected]>
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (5802)

Russ Housley <[email protected]> wrote:
> At the time that these values were assigned, TLS was primarily a 
> protocol for WWW security.  It has since been used in may other 
> environments.  I do not see how a change to the comment in the
> ASN.1 definition will make any real difference, but I do not really 
> have an objection.
> 
> I suggest that this be marked as "Hold for Document Update"


The applicable **STANDARDS** in this area would be
rfc5246 (TLSv1.2) and rfc2818 (HTTP over TLS), and both are
**SILENT** on EKU.

What openssl does is a non-standard, implementation-defined behaviour, and I
consider it a particularly bad idea trying to rewrite history by filing this
as an errata !


I've also seen a public CA (Entrust) issue a TLS server certificate which
asserted id-kp-serverAuth, but was lacking id-kp-clientAuth.
I consider such a certificate a stupid clerical error by Entrust.

[JLS]  I would consider this to be correct behavior.  My reading is that
id-kp-clientAuth is going to be in the client certificate that is being used
to authenticate to the server.  No a statement that the server wants or can
do client auth.

Whether TLS client software is willing to use such a certificate as TLS
client certificate, and whether TLS server software is willing to accept
such a TLS server certificate as TLS client certificate turns out to be
*VERY* implementation-specific.


If changing the limited-applicability comment in rfc5280 for
id-kp-serverAuth and id-kp-clientAuth at all, then it should also include
which **application**standards**, if any, gives any meaning to these EKUs,
and where application standards have *NOT* been giving any meaning all the
time, the behaviour is implementation-defined at best.

[JLS]  I have no opinion on this one way or the other

Jim


-Martin

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix