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

Rob Stradling rob at sectigo.com
Fri Dec 21 08:29:34 MST 2018

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.


> 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 

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

More information about the Servercert-wg mailing list