Re: In-the-wild implementations of RFC6955?

On 5/24/2022 2:22 AM, Peter Gutmann wrote:
> Michael StJohns<[email protected]>  writes:
>
>> Is anyone aware of
>>
>> a)  implementation of CSR software which can generate requests for ECDH
>> certificates
> [crickets]
>
> While it's difficult to prove a negative, ECDH certs are just a rerun of DH
> certificates from 20 years ago, which were supported by exactly nobody [0], so
> I would assume it's no different for ECDH certs.
>
> In addition even if you could somehow generate an (EC)DH cert I'd be even more
> surprised if you could find anything that knew what to do with it when it saw
> it.

Well, TLS1.1 has ECDH_ECDSA and ECDH_RSA capable cipher suites and 
https://datatracker.ietf.org/doc/html/rfc4346#section-7.4.2 indicates 
that the server certificates associated with DH_DSS and DH_RSA have to 
have the keyAgreement bit set.  Strangely 
https://datatracker.ietf.org/doc/html/rfc4492#section-5.3 which is in 
the document that actually defines the ECDH_* suites doesn't mention 
setting this bit.

>From 
https://security.stackexchange.com/questions/24106/which-key-usages-are-required-by-each-key-exchange-method 
I got the claim that OpenSSL required this bit to be set for ECDH_* 
suites for TLS1.2 - I may peruse the code and see if this is true.  But 
I can't find a specification document that requires this.

I *think* that the ECDH_* suites were proposed for two reasons: 1) 
symmetry with the DH_* suites. 2) Because at the time generating ECDHE 
key pairs for large numbers of incoming connections  might tax the 
ability of the web server (e.g. twice as many point multiplications plus 
a need for a fairly fast RBG). The text of RFC4492 hints at the latter:

> Here
>     again the security benefits of forward secrecy may need to be
>     balanced against the improved efficiency offered by other options.

>
> So just out of curiosity, to help understand the use case since I've never
> seen one before and it'd be interesting to hear about it, please lie on this
> couch and tell me why/how you're planning on using these things.  And
> remember, this is for posterity, so be honest — how do ECDH certs make you
> feel?

*laugh* You channeling Count Rugen from Princess Bride is somewhat scary.

As for use case, I've been trying to get the details for a few days, but 
so far haven't heard back.  I had gotten a request to help one of my 
contracts understand how to implement support for various forms of 
PKCS10 CSRs, including one with only keyAgreement as a proposed keyUsage 
extension and was a bit surprised as I'd never seen such a beast.  The 
sample keyAgreement only CSR came in as ECDSA signed - which is both 
pragmatic and wrong.

> Peter.
>
> [0] Well, a few implementations went through the motions of half-hearted token
>      support so they couldn't be accused of being non-standards-compliant, but
>      not much more than that.
>
Thanks - Mike

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