[Servercert-wg] [cabfpub] Interest in Ed25519 and/or Ed448?

[Rob Stradling]

On 20/12/2018 15:13, Ryan Sleevi wrote:
> On Thu, Dec 20, 2018 at 6:53 AM Rob Stradling wrote:
> 
>     Maybe I can't ask that secondary question until after the Code Signing
>     and S/MIME WGs have been chartered.
> 
> 
> Right, I would expect that even if we had such a list, cross-posting 
> would be discouraged / prohibited, given the nature of both IPR 
> commitments and given that we should not assume all members will be in 
> all WGs. At the present, it seems best that any discussions outside of 
> Forum-level business or chartering of WGs would best be discussed on the 
> applicable WG.

Thanks Ryan.  I hadn't considered that cross-posting might be affected 
by IPR!

> Despite being an "easy" question about what you're asking, there's 
> actually two questions/parts to unpack.
> 
> 1) Do browsers have plans to support Ed25519/Ed448 SPKIs in leaf 
> certificates?
> 2) Do browsers have plans to support Ed25519/Ed448 signatures anywhere 
> in the certificate chain (which implies SPKIs in non-leaf certificates)?
> 
> I think any discussion about what that means has to consider the 
> discussions in the IETF TLS 1.3 WG regarding RSA-PSS, as the nuances and 
> trade-offs are the same. Those discussions highlighted the tendency of 
> some cryptographic libraries to choke on leaf SPKIs they don't recognize 
> - even if the client implementation may allow them - and the challenges 
> with deploying new signature algorithms in certificates vs TLS.
> 
> On the basis of the strong, widespread, International community review 
> and consensus in evaluating these algorithms, as captured through the 
> discussions of the IETF and CFRG, we're supportive of these algorithms 
> and would like to support them in Chrome.
> 
> Regarding the first question, our integration with certain OS 
> cryptographic functions to enable easier administration and "out of the 
> box" experience for Enterprises and home users presents some challenges 
> to that support, as alluded to above, and so we have nothing concrete to 
> share at this time beyond that expression of support and eventual intent.

Understood.

> Regarding the second question, we are still awaiting discussions about 
> how to best produce such signatures while still ensuring the keys used 
> to produce such signatures are reasonably, meaningfully, and 
> demonstrably protected. Until we see work progressing on those 
> protection profiles, we're concerned that shipping such support may be 
> seen as encouraging weaker standards for key protection, given that is 
> the only way to produce such signatures. While the dependencies overlap 
> with those of the first question - that is, they are certainly a 
> technical precondition - we're unlikely to enable support for a 
> signature algorithm prior to it being usable in the contexts we are 
> concerned about, and we're unlikely to support it being usable in the 
> contexts we are concerned about without there being a path to ensure 
> meaningful, widely-accepted key protection in those contexts.

Do you have a clear list of targets that would need to be met for 
Ed25519/Ed448 to be "useable in the contexts" that you "are concerned 
about"?

For example, are you waiting for Ed25519/Ed448 to become incorporated 
into FIPS-140 certifications?  Or would it be enough for just one HSM 
vendor to ship support for Ed25519/Ed448 in at least one model of HSM, 
and for that HSM to be operated in "non FIPS mode"?

Or is it too early to be asking these questions?

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited