Re: [lamps] Comment on draft-ietf-lamps-cert-binding-for-multi-auth

[Russ Housley <[e-mail]>]

The authors need to address the comments from Roman's AD Review.  I ask the authors to consider this comment at the same time.

Russ


> On Mar 20, 2024, at 1:11 PM, Daniel Van Geest <[e-mail]> wrote:
> 
> I was just going through draft-ietf-lamps-cert-binding-for-multi-auth again and noticed something I thought was worth bringing up.  I didn’t find any mention of this on the mailing list.
>  
> Section 4.1 says:
>    The
>    algorithm used to hash the certificate in the RelatedCertificate
>    extension MUST match the hash algorithm used to sign the certificate
>    that contains the extension.
>  
> I wonder if that is not explicit enough.  Ed{25519,448}*, ML-DSA** and SLH-DSA** don’t have pre-hashing, so no hash algorithm is communicated in the certificate as part of the signature algorithm identifier.  Is a developer expected to dig into the Ed25519 spec to know that SHA-512 should be used?  SLH-DSA, okay the hash algorithm is in the name of the parameter set.  ML-DSA uses both SHAKE128 and SHAKE256 internally, but SHAKE256 is used to generate the message representative.  What happens if a new signature algorithm comes along that does something more esoteric and harder to determine “the hash algorithm” of the signature?  It’s not a signature algorithm, but any particular variant of ML-KEM uses all of SHAKE128, SHAKE256, SHA3-256 and SHA3-512 internally.
>  
> Not communicating the hash algorithm in the extension seems like it’s setting us up for development errors and other future problems.
>  
> Also (not a personal concern, but now this thought is haunting me everywhere thanks to feedback on the cms-kyber draft): “what if SHA3/SHAKE isn’t available at the X.509 level, only at the crypto level?”
>  
> Are these reasonable concerns?
>  
> * Ed{25519,448}ph is not specified for use in LAMPS.
> **unless updated by NIST, and even then we may not want to use prehashing for certificate signatures.
>  
> Apologies for noticing this so late in the game,
>  
> Daniel Van Geest