Hi Mike,

Yeah, this point is one that I hadn’t thought to bring up in the presentation, 
but that I also think is one of the things that will require pushing from both 
sides; as long as KEMs in certs are a niche use case, then we don’t have a lot 
of motivation to really start having these discussions on the PKI side…

Cheers,

Thom

> Op 6 nov 2023, om 16:17 heeft Mike Ounsworth <[email protected]> het 
> volgende geschreven:
> 
> Hi Thom,
>  
> Your presentation today was good, but I just want to point out an elephant in 
> the room that’s missing from your slides: Public PKI is not currently 
> equipped to issue KEM certificates because every cert enrollment protocol 
> that I can think of uses CSRs at the bottom, and you can’t sign a CSR with a 
> KEM key. Back in 2021 I did some digging into which PKI enrollment protocols 
> have Proof-of-Possession (PoP) mechanisms for encryption keys, which I 
> presented at the Jan 2021 LAMPS Interim – see Slide 27 [1]; missing from that 
> slide is: “ACME: No”. If tls-authkem progresses, then we as a community need 
> to have a whole debate about how much we care about PoP for cert enrollment 
> and whether we’re ok for CAs to accept un-protected CSRs (just nothing in the 
> signature field), or whether we want to go down the rabbit hole of Zero 
> Knowledge Proof based CSR protection such as the one proposed in [2], or 
> re-design cert enrollment protocols to protect KEM CSRs in some other way 
> (like CSRs signed with the ACME account key).
>  
> I am not trying to slow down draft-tls-authkem because it’s good work, but 
> please don’t overlook that WebPKI is not currently equipped to issue KEM 
> certificates and there is a fairly large amount of pre-requisite work that 
> would need to happen before we can deploy tls-authkem at any kind of scale.
>  
> [1]: 
> https://datatracker.ietf.org/doc/slides-interim-2021-lamps-01-sessa-position-presentation-by-mike-ounsworth/
> [2]: https://dl.acm.org/doi/abs/10.1145/3548606.3560560
>  
> ---
> Mike Ounsworth
> Software Security Architect, Entrust
>  
> Any email and files/attachments transmitted with it are intended solely for 
> the use of the individual or entity to whom they are addressed. If this 
> message has been sent to you in error, you must not copy, distribute or 
> disclose of the information it contains. Please notify Entrust immediately 
> and delete the message from your system.

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

Reply via email to