Subject: [lamps] Proposed charter update regarding clarifications

From: Russ Housley <[email-masked]>
Date: Sat, 27 Jul 2019 07:40:05 -0400

At the meeting in Montreal, we suggested a charter update to allow clarifications.  I suggest:

OLD:

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WGs, but the LAMPS WG shall not adopt
any of these potential work items without rechartering.

NEW:

In addition, the LAMPS WG may investigate other updates to documents
produced by the PKIX and S/MIME WG. The LAMPS WG may produce
clarifications where needed, but the LAMPS WG shall not adopt
anything beyond clarifications without rechartering.

Thoughts?

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 27 Jul 2019 17:03:03 +0100

> anything beyond clarifications without rechartering.

Seems like another step on the road to re-creating PKIX
which at the end produced pointless paper. IMO nothing
should be done in this WG unless there's evidence the
work will be implemented and deployed.

S.

> 
> Russ
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 27 Jul 2019 16:16:54 +0000

+1  Maybe plural WGs?

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 27 Jul 2019 12:19:54 -0400

> work will be implemented and deployed.

While I share the general sentiment, there is at least one clarification
which has clear signs of deployment if there is IETF consensus on the text
-
https://tools.ietf.org/id/draft-turner-5480-ku-clarifications-00.html

For example,
https://github.com/zmap/zlint/pull/293 is used by the majority of the
publicly trusted CAs, directly or indirectly, and would actively enforce
such text.

I too appreciate a narrowed scope, and wouldn’t be too miffed if any/every
clarification was a matter for rechartering, and the WG only looked at
chartering with this in scope.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 27 Jul 2019 17:42:25 -0400

> clarifications.  I suggest:

This change would seem to work for my document and subsequent equivalent
ones.

    > clarifications where needed, but the LAMPS WG shall not adopt anything
    > beyond clarifications without rechartering.

    > Russ _______________________________________________ Spasm mailing list
    > [email-masked] https://www.ietf.org/mailman/listinfo/spasm

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Mon, 29 Jul 2019 12:13:52 +0000

I would be happy with the current text. But I guess there will be the need for many updates at least with regard to support of upcoming crypto algorithms. Therefore the new text will ease the processes.
Finally it will be a trade-off between administrative overhead vs. risk of 'pointless paper'. Finally I am with Stephen, that nothing should be done without people willing to implement it.

Hendrik

> -----Ursprüngliche Nachricht-----
> Von: Spasm <[email-masked]> Im Auftrag von Russ Housley
> Gesendet: Samstag, 27. Juli 2019 13:40
> An: LAMPS WG <[email-masked]>
> Betreff: [lamps] Proposed charter update regarding clarifications
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww
> .ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.
> brockhaus%40siemens.com%7C28e8b2e7640e486105ab08d712873521%7C38
> ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C636998244239259100&am
> p;sdata=5wTBzw09KsNOVU%2FOZAIi94fIzXu2UZ%2Bm%2B12sIf%2FRS4w%3
> D&amp;reserved=0

---

From: Russ Housley <[email-masked]>
Date: Mon, 29 Jul 2019 10:22:22 -0400

How does the update to RFC 5480 about key usage fit here?

Russ

> On Jul 29, 2019, at 8:13 AM, Brockhaus, Hendrik <[email-masked]> wrote:
>

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 30 Jul 2019 12:38:16 +0000

I see this as a clarification that is correct but no necessarily needed, as direct encipherment is technically not possible with ec-keys.
But it may be helpful to have this more explicitly as currently specified.

Hendrik

> Gesendet: Montag, 29. Juli 2019 16:22
> An: Brockhaus, Hendrik (CT RDA CST SEA-DE)
> <[email-masked]>
> Cc: LAMPS WG <[email-masked]>
> Betreff: Re: [lamps] Proposed charter update regarding clarifications
> 
> > I would be happy with the current text. But I guess there will be the need
> for many updates at least with regard to support of upcoming crypto
> algorithms. Therefore the new text will ease the processes.
> > Finally it will be a trade-off between administrative overhead vs. risk of
> 'pointless paper'. Finally I am with Stephen, that nothing should be done
> without people willing to implement it.
> >
> > Hendrik
> >
> >> https://www
> .
> ietf.org%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.b
> rock
> >
> haus%40siemens.com%7C6192e50f83614e861f7208d714303717%7C38ae3bcd
> 95794f
> >
> d4addab42e1495d55a%7C1%7C0%7C637000069621473442&amp;sdata=X5Kto
> 6cOEfFt
> > lPEfePsHx23ouMD7dKXRpP5JeBfqhnw%3D&amp;reserved=0
> 
> brockhaus%40siemens.com%7C6192e50f83614e861f7208d714303717%7C38a
> e3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637000069621473442&amp;
> sdata=X5Kto6cOEfFtlPEfePsHx23ouMD7dKXRpP5JeBfqhnw%3D&amp;reserv
> ed=0

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 30 Jul 2019 10:03:49 -0400

>
> I see this as a clarification that is correct but no necessarily needed,
> as direct encipherment is technically not possible with ec-keys.

Hi Hendrik,

I respectfully disagree that this is not needed. The existing language
doesn't make this technical impossibility clear enough to prevent
certificates with such key usage bits being seen in the real world. The
more certificates with such nonsense KU's are produced the more likely it
will be that other systems begin to special case this phenomenon,
increasing complexity and the chance for more significant errors.

If you chase the links through the zlint PR[0] I wrote that Ryan referenced
earlier in thread you'll find your way to a Bugzilla bug[1] that references
~30 certificates issued by a trusted CA that contain the technically
impossible KU in question (here's one example[2]). My experience within the
larger web PKI ecosystem suggests to me this could be just the tip of the
iceberg.

I deeply sympathize with Stephen's appeal to not produce more useless paper
but the update to RFC 5480 won't fall into this category. An update to RFC
5480 will both clarify a point that is causing demonstrated confusion for
implementors and make it easier for the web PKI community to forbid the
practice with haste.

[0]: https://github.com/zmap/zlint/pull/293
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1560234
[2]: https://crt.sh/?id=741149075

On Tue, Jul 30, 2019 at 8:38 AM Brockhaus, Hendrik <
[email-masked]> wrote:

> I see this as a clarification that is correct but no necessarily needed,
> as direct encipherment is technically not possible with ec-keys.

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Tue, 30 Jul 2019 14:21:20 +0000

You are absolutely right, the draft makes it more explicit for all those who did not knew it before and this will help you to clarify it.

Von: Daniel McCarney <[email-masked]>
Gesendet: Dienstag, 30. Juli 2019 16:04

Hi Hendrik,

I respectfully disagree that this is not needed. The existing language doesn't make this technical impossibility clear enough to prevent certificates with such key usage bits being seen in the real world. The more certificates with such nonsense KU's are produced the more likely it will be that other systems begin to special case this phenomenon, increasing complexity and the chance for more significant errors.

If you chase the links through the zlint PR[0] I wrote that Ryan referenced earlier in thread you'll find your way to a Bugzilla bug[1] that references ~30 certificates issued by a trusted CA that contain the technically impossible KU in question (here's one example[2]). My experience within the larger web PKI ecosystem suggests to me this could be just the tip of the iceberg.

I deeply sympathize with Stephen's appeal to not produce more useless paper but the update to RFC 5480 won't fall into this category. An update to RFC 5480 will both clarify a point that is causing demonstrated confusion for implementors and make it easier for the web PKI community to forbid the practice with haste.

[0]: https://github.com/zmap/zlint/pull/293<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fzmap%2Fzlint%2Fpull%2F293&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107435388&sdata=8W8QhfxIjW12TMqe5%2BbBWNuIjsHOxZMeAzE9eF9h5OE%3D&reserved=0>
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1560234<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1560234&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107445386&sdata=gE7%2FyXX4bNfslnYONsuc1nNeuVuPJV%2FeJmDy7p%2FyZ1g%3D&reserved=0>
[2]: https://crt.sh/?id=741149075<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrt.sh%2F%3Fid%3D741149075&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107445386&sdata=oYikrYWgaObljeKV4rbyOXI1cleCuBG56unltcxmLFg%3D&reserved=0>

On Tue, Jul 30, 2019 at 8:38 AM Brockhaus, Hendrik <[email-masked]<mailto:[email-masked]>> wrote:
I see this as a clarification that is correct but no necessarily needed, as direct encipherment is technically not possible with ec-keys.
But it may be helpful to have this more explicitly as currently specified.

Hendrik

> Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Russ Housley
> <[email-masked]<mailto:[email-masked]>>
> Cc: LAMPS WG <[email-masked]<mailto:[email-masked]>>
> > On Jul 29, 2019, at 8:13 AM, Brockhaus, Hendrik
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >> Von: Spasm <[email-masked]<mailto:[email-masked]>> Im Auftrag von Russ Housley
> >> An: LAMPS WG <[email-masked]<mailto:[email-masked]>>
> >> [email-masked]<mailto:[email-masked]>
> >> https://www
> >>
> .ietf.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107455375&sdata=aW6wWaM87aoQqG10lbzbpgWakCmAb0CUOn3nzTMZFvc%3D&reserved=0>%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.
> >>
> brockhaus%40siemens.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40siemens.com&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107455375&sdata=bpob1bOLkZDdv2BtDPe7Bsmr4%2B%2Fd6owyssImsLkbrdM%3D&reserved=0>%7C28e8b2e7640e486105ab08d712873521%7C38
> >>
> > [email-masked]<mailto:[email-masked]>
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www>
> .
> >
> ietf.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107465379&sdata=LGEoAm%2BZPIyd2OYQfh%2BIlcrzEifHeTDhAfGx8Qe3Mfo%3D&reserved=0>%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.b
> rock
> >
> haus%40siemens.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40siemens.com&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107465379&sdata=MYgJ%2F6%2BeOjIV3I9efFzxSkQ%2F4CMEjTo6hWqcCheJ6lE%3D&reserved=0>%7C6192e50f83614e861f7208d714303717%7C38ae3bcd
> 95794f
> >
> [email-masked]<mailto:[email-masked]>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww<https://www>
> .ietf.org<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fietf.org&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107475371&sdata=aprBNKcFf5Lg3zqKAMuqhsMW7FS%2Bif964aBydedjVjY%3D&reserved=0>%2Fmailman%2Flistinfo%2Fspasm&amp;data=02%7C01%7Chendrik.
> brockhaus%40siemens.com<https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40siemens.com&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107475371&sdata=hj5KGznE47X2apk5eaf59B4RKFc9P3QqIZHEPGz2ZtU%3D&reserved=0>%7C6192e50f83614e861f7208d714303717%7C38a
_______________________________________________
Spasm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cefa81101b4bb4ad4443908d714f6eece%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C1%7C637000923107475371&sdata=%2BB%2FzCDhLmKWYIGhM9ztdPUVUeE9rjij9P%2BKjTZHnops%3D&reserved=0>