Re: [lamps] LAMPS WG Last Call for draft-ietf-lamps-5480-ku-clarifications-00

[Ryan Sleevi <[e-mail]>]

On Wed, Jan 8, 2020 at 3:04 PM Stephen Farrell <[e-mail]>
wrote:

>
> 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 re-read it and support it.

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

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