Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (5802)

From: Russ Housley <[email-masked]>
Date: Tue, 6 Aug 2019 12:15:44 -0400

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"

Russ

> On Aug 6, 2019, at 11:56 AM, RFC Errata System <[email-masked]> wrote:
> 
> The following errata report has been submitted for RFC5280,
> "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5802
> 
> --------------------------------------
> Type: Technical
> Reported by: Nikos Mavrogiannopoulos <[email-masked]>
> 
> Section: 4.2.1.12
> 
> Original Text
> -------------
>  id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
>  -- TLS WWW server authentication
>  -- Key usage bits that may be consistent: digitalSignature,
>  -- keyEncipherment or keyAgreement
> 
>  id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
>  -- TLS WWW client authentication
>  -- Key usage bits that may be consistent: digitalSignature
>  -- and/or keyAgreement
> 
> Corrected Text
> --------------
>  id-kp-serverAuth             OBJECT IDENTIFIER ::= { id-kp 1 }
>  -- TLS server authentication
>  -- Key usage bits that may be consistent: digitalSignature,
>  -- keyEncipherment or keyAgreement
> 
>  id-kp-clientAuth             OBJECT IDENTIFIER ::= { id-kp 2 }
>  -- TLS client authentication
>  -- Key usage bits that may be consistent: digitalSignature
>  -- and/or keyAgreement
> 
> Notes
> -----
> The proposed change removes the WWW part of the description. In practice these object identifiers are used for server and client applications, but not necessarily web applications. In particular:
> - openssl verification considers them unconditionally even if the server is not a web server or the client a web client
> - There is no object identifier that can be used for protocols like SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols are deployed with the identifiers for WWW
> - Standards like common criteria assume that these object identifiers are for generic server and clients [0].
> 
> [0]. https://www.niap-ccevs.org/MMO/PP/-442-/#FCS_TLSC_EXT.1.1
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5280 (draft-ietf-pkix-rfc3280bis-11)
> --------------------------------------
> Title               : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
> Publication Date    : May 2008
> Author(s)           : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk
> Category            : PROPOSED STANDARD
> Source              : Public-Key Infrastructure (X.509)
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Aug 2019 10:28:03 -0700

Looking at the document, this is not a comment in the ASN.1 definition as it
is not part of the ASN.1 module at the bottom of the file.   However I agree
that just updating this apparent comment would not make any real difference
and "Hold for Document Update" is appropriate.

Jim

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

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.

Russ

> The following errata report has been submitted for RFC5280, "Internet 
> X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile".
> The proposed change removes the WWW part of the description. In practice
these object identifiers are used for server and client applications, but
not necessarily web applications. In particular:
> - openssl verification considers them unconditionally even if the 
> server is not a web server or the client a web client
> - There is no object identifier that can be used for protocols like 
> SMTP, IMAP, POP3, LDAP, radius, ...; in practice all these protocols 
> are deployed with the identifiers for WWW
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party can log in to change 
> the status and edit the report, if necessary.
> 
> Title               : Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile
> Source              : Public-Key Infrastructure (X.509)

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

---

From: [email-masked] (Martin Rex)
Date: Tue, 6 Aug 2019 23:21:46 +0200 (CEST)

Russ Housley <[email-masked]> 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.
> 

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.

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.

-Martin

---

From: Jim Schaad <[email-masked]>
Date: Tue, 6 Aug 2019 15:57:27 -0700

-----Original Message-----
From: pkix <[email-masked]> On Behalf Of Martin Rex
Sent: Tuesday, August 6, 2019 2:22 PM
To: Russ Housley <[email-masked]>
Cc: Roman D. Danyliw <[email-masked]>; Ben Kaduk <[email-masked]>; IETF PKIX
<[email-masked]>

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 8 Aug 2019 15:51:35 -0500

Hi Martin,

> giving any meaning all the time, the behaviour is implementation-defined

We're not changing anything, here; we're just making a note that the
unfortunate people stuck doing a bis of this document should look at this
one issue.  If you think they should also look at an other (related) issue
at the same time, you are free to submit a separate errata report, but I
don't see much reason to think that the two topics should be consolidated
into a single report.

I plan to mark this as HFDU as Russ suggests.

-Ben