Re: [Gen-art] [lamps] Gen-ART Last Call review of draft-ietf-lamps-rfc3709bis-06

[Russ Housley <[e-mail]>]

Paul:

>>> 1) MINOR: In Section 4.1 (Extension Format):
>>> 
>>> The following:
>>> 
>>> "CAs SHOULD use the one-way hash function that is associated with the certificate signature to compute the hash value, and CAs MAY include other hash values."
>>> 
>>> introduces the possibility that a client might not support *any* of the provided hash algorithms. This seems bad.
>>> 
>>> RFC3709 didn't have this problem because it required that an SHA-1 hash be included and supported.
>>> 
>>> This can be fixed by changing "CAs SHOULD" to "CAs MUST".
>> We are seeing a few signature algorithms that are not following the hash-then-sign pattern. I'm not sure how to allow the signature on the certificate to use one of them (like EdDSA) when one has to know a lot about the algorithm details to determine which hash is used internally.  As you say, the "CAs MUST" would require the certificate issuer to do that research.  Do others have an opinion?
> 
> Well then, how about picking some algorithm (to replace SHA-1) that clients must support and that must be used in cases when cert signature algorithm can't be used?
> 
> Or worst case, discuss what is to be done by a client who doesn't support any of the offered hash algorithms.

I copied the WG on my reply.  I'd like to hear what others think before proposing text.

Russ