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

[Daniel Van Geest <[e-mail]>]

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