Subject: [lamps] I-D Action: draft-ietf-lamps-5480-ku-clarifications-00.txt

From: [email-masked]
Date: Wed, 08 Jan 2020 10:05:30 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Limited Additional Mechanisms for PKIX and SMIME WG of the IETF.

        Title           : Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information
        Authors         : Tadahiko Ito
                          Sean Turner
	Filename        : draft-ietf-lamps-5480-ku-clarifications-00.txt
	Pages           : 3
	Date            : 2020-01-08

Abstract:
   This document updates RFC 5480 to specify semantics for the
   keyEncipherment and dataEncipherment key usage bits when used in
   certificates that support Elliptic Curve Cryptography.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lamps-5480-ku-clarifications-00
https://datatracker.ietf.org/doc/html/draft-ietf-lamps-5480-ku-clarifications-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Turner <[email-masked]>
Date: Wed, 8 Jan 2020 13:11:58 -0500

Hi! This is the initial version of the draft.  Note it is identical to draft-turner-5480-ku-clarifications except for the dates, WG is now LAMPS and not TBD, and the dates.

Since this is such a simple draft and I incorporated the only comment to date, can I humbly request a WGLC ;)

spt

> On Jan 8, 2020, at 13:05, [email-masked] wrote:
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Russ Housley <[email-masked]>
Date: Wed, 8 Jan 2020 14:51:07 -0500

This is a very short document, and it had some review prior to WG adoption.  So, now that the document has been adopted, I think it is ready for WG Last Call.

This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information" <draft-ietf-lamps-5480-ku-clarifications-00>.  Please review the document and send your comments to the list by 24 January 2020.

The datatracker page for the document is https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications-00/

Thanks,
Russ & Tim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 8 Jan 2020 20:04:11 +0000

Hiya,

On 08/01/2020 19:51, Russ Housley wrote:
> This is a very short document, and it had some review prior to WG
> adoption.  So, now that the document has been adopted, I think it is
> ready for WG Last Call.
> 
> This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve
> Cryptogtaphy Subject Public Key Information"
> <draft-ietf-lamps-5480-ku-clarifications-00>.  Please review the
> document and send your comments to the list by 24 January 2020.

I would support publication if someone tells me that
they've done a survey (via e.g. zmap/zgrab or crt.sh)
and found that there are zero or only a tiny percentage
of issued certificates that conflict with the draft.

If that happened already apologies and great!

If not, shouldn't that be done before declaring success
on WG last-call?

> 
> The datatracker page for the document is
> https://datatracker.ietf.org/doc/draft-ietf-lamps-5480-ku-clarifications-00/

That gets a 404, should be [1] I guess.

Cheers,
S.

[1]

>
>  Thanks, Russ & Tim _______________________________________________ 
> Spasm mailing list [email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Jan 2020 20:07:35 +0000

>    This is the LAMPS WG Last Call for "Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key Information" <draft-ietf-lamps-5480-ku-clarifications-00>.  Please review the document and s…
 
Just re-read it.  Ship it :)

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 8 Jan 2020 15:37:59 -0500

> > document and send your comments to the list by 24 January 2020.

I re-read it and support it.

> If not, shouldn't that be done before declaring success

Could you explain the objective? =)

That is, part of the reason for this is to clarify whether or not it's
expected or not. The suggestion was rather than the CABF profile to
explicitly say it's not expected/allowed, to address this and clarify in
the IETF whether the omission of elements from the extant MAY implies a
MUST NOT.

This is part of a broader effort in the CA/Browser Forum of clarifying that
if things are not explicitly allowed, they should be interpreted as
forbidden. In the context of ECDSA, is there a situation where those
keyUsages makes sense and aligns with those key algorithms? Arguably, no,
hence the draft to make it clear ;)

That said, you can run a Censys query with the following:
parsed.subject_key_info.key_algorithm.name: "ECDSA" and
(parsed.extensions.key_usage.data_encipherment: true or
parsed.extensions.key_usage.key_encipherment: true)
https://censys.io/certificates?q=parsed.subject_key_info.key_algorithm.name%3A+%22ECDSA%22+and+%28parsed.extensions.key_usage.data_encipherment%3A+true+or+parsed.extensions.key_usage.key_encipherment%3A+true%29

For what it's worth, a number of PKI libraries will reject these
certificates as invalid, which will not even allow the user to bypass the
error, as they've interpreted the extant language as being what this draft
codifies.

The quick summary of those results, run just now:
46.36K Never Trusted
39.72K Expired
38.95K Unexpired
31.48K Self-Signed
1,628 CT
1,628 Google CT
1,217 CT PreCert
840 Leaf
828 EV
774 Previously Trusted
416 DV
299 OV
66 Currently Trusted

17.76K Freebox SA
14.03K Philips Hue
9,942 Caddy Self-Signed
5,927 CloudFlare, Inc.
2,261 Docker
1,551 Mesosphere, Inc.
968 Mesosphere Inc.
927 McAfee, Inc.
920 NoEnv
808 Jungheinrich AG
640 Gemalto
488 Bird Home Automation
477 GlobalSign nv-sa
449 Developer Certificate
406 A1A Car Wash
399 StartCom Ltd.
377 Entrust, Inc.
342 VirtuallyLive
274 SpectraLogic
248 DNSFilter

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 10 Jan 2020 14:20:06 -0500

Hi folks,

I was curious about the high number of ECDSA certs with bad KU associated
with the Caddy project in Ryan's Censys summary. I opened an issue with the
project[0] and the primary author pointed out that he took the code at
fault from the Go standard library's `generate_cert.go` utility. I've
opened an issue[1] with the Go folks to get that fixed but in the process
noticed that the tool sets the KeyUsage field incorrectly for both ECDSA
and ED25519 subject public keys.

This led me to notice that RFC 8410's section on "Key Usage bits"[2] is
missing the "keyEncipherment and dataEncipherment usages MUST NOT be
present" language that draft-ietf-lamps-5480-ku-clarifications-00 is adding
to RFC 5480.

Would the WG be interested in updating RFC 8410 with similar clarification?
I believe the keyEncipherment and dataEncipherment key usages are equally
inappropriate for these algorithms as for ECDSA but I'm open to schooling
if I've made a mistake in my analysis.

Thanks,

[0]: https://github.com/caddyserver/caddy/issues/2969
[1]: https://github.com/golang/go/issues/36499
[2]: https://tools.ietf.org/html/rfc8410#section-5

On Wed, Jan 8, 2020 at 3:38 PM Ryan Sleevi <[email-masked]> wrote:

> This is part of a broader effort in the CA/Browser Forum of clarifying
> that if things are not explicitly allowed, they should be interpreted as
> parsed.subject_key_info.key_algorithm.name
> <http://parsed.subject_key_info..key_algorithm.name>: "ECDSA" and

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Jan 2020 21:12:38 +0000

Hiya,

Thanks for the censys link, was hoping someone else'd do
the work to generate something like that:-)

> Could you explain the objective? =)

So those numbers, when compared to the overall number of
ecdsa certs [1] seem to imply that some issuers get (or
used get) this wrong for all or almost all their certs,
(as Daniel's mail about caddy indicated) albeit the numbers
for such issuers are quite small compared to the bigger
issuers. "Freebox SA" for example issued 17.87K ecdsa
certs according to [1] and 17.76K broken according to the
numbers you posted.

For me, that means that if we proceed with this then
we're kinda breaking some smaller folks stuff in a sense.
(Yeah, they broke it first, but still;-)

I'd say attempting to let 'em know would be a fine thing,
while also processing this draft.

Again though, I'm not objecting to processing the draft,
but if we're doing it so quickly and it may be perceived
as causing breakage, (even if it's drawing attention to,
rather than causing, breakage) then raising issues etc.
(as Daniel did) seems like a better way to do this than
just firing ahead at full-speed.

Cheers,
S.

[1]
https://censys.io/certificates?q=parsed.subject_key_info.key_algorithm.name%3A+%22ECDSA%22

---

From: Sean Turner <[email-masked]>
Date: Fri, 10 Jan 2020 17:49:00 -0500

I wouldn’t mind taking that on, but I’d really rather do it in another draft.

spt

> On Jan 10, 2020, at 14:20, Daniel McCarney <[email-masked]> wrote:
> 
> Hi folks,
> 
> I was curious about the high number of ECDSA certs with bad KU associated with the Caddy project in Ryan's Censys summary. I opened an issue with the project[0] and the primary author pointed out that he took the code at fault from the Go standard library's `generate_cert.go` utility. I've opened an issue[1] with the Go folks to get that fixed but in the process noticed that the tool sets the KeyUsage field incorrectly for both ECDSA and ED25519 subject public keys.
> 
> This led me to notice that RFC 8410's section on "Key Usage bits"[2] is missing the "keyEncipherment and dataEncipherment usages MUST NOT be present" language that draft-ietf-lamps-5480-ku-clarifications-00 is adding to RFC 5480.
> 
> Would the WG be interested in updating RFC 8410 with similar clarification? I believe the keyEncipherment and dataEncipherment key usages are equally inappropriate for these algorithms as for ECDSA but I'm open to schooling if I've made a mistake in my analysis.
> 
> Thanks,
> 
> On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell <[email-masked]> wrote:
> 
> Hiya,
> 
> That is, part of the reason for this is to clarify whether or not it's expected or not. The suggestion was rather than the CABF profile to explicitly say it's not expected/allowed, to address this and clarify in the IETF whether the omission of elements from the extant MAY implies a MUST NOT.
> 
> This is part of a broader effort in the CA/Browser Forum of clarifying that if things are not explicitly allowed, they should be interpreted as forbidden. In the context of ECDSA, is there a situation where those keyUsages makes sense and aligns with those key algorithms? Arguably, no, hence the draft to make it clear ;)
> 
> parsed.subject_key_info.key_algorithm.name: "ECDSA" and (parsed.extensions.key_usage.data_encipherment: true or parsed.extensions.key_usage.key_encipherment: true)
> For what it's worth, a number of PKI libraries will reject these certificates as invalid, which will not even allow the user to bypass the error, as they've interpreted the extant language as being what this draft codifies.
>

---

From: Daniel McCarney <[email-masked]>
Date: Sat, 11 Jan 2020 10:19:30 -0500

+1 to a separate draft.

On Fri, Jan 10, 2020 at 7:37 PM Sean Turner <[email-masked]> wrote:

> > I was curious about the high number of ECDSA certs with bad KU
> associated with the Caddy project in Ryan's Censys summary. I opened an
> issue with the project[0] and the primary author pointed out that he took
> the code at fault from the Go standard library's `generate_cert.go`
> utility. I've opened an issue[1] with the Go folks to get that fixed but in
> the process noticed that the tool sets the KeyUsage field incorrectly for
> both ECDSA and ED25519 subject public keys.
> >
> > Would the WG be interested in updating RFC 8410 with similar
> clarification? I believe the keyEncipherment and dataEncipherment key
> usages are equally inappropriate for these algorithms as for ECDSA but I'm
> open to schooling if I've made a mistake in my analysis.
> >
> > Thanks,
> >

---

From: Russ Housley <[email-masked]>
Date: Fri, 24 Jan 2020 13:07:55 -0500

Thanks for the discussion.  I see consensus for publication.  I will begin preparing a document shepherd write-up.

Russ

> On Jan 8, 2020, at 2:51 PM, Russ Housley <[email-masked]> wrote:
>