RE: [TLS] Signature Hash Agility
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [TLS] Signature Hash Agility



Eric Rescorla wrote:

> 3. Communicating the signature/hash algorithm you're using So, I
> agree that trying to figure out the hash from the signature
> algorithm in the cert was a mistake. We clearly need to explicitly
> name the digest algorithm in the message. However, previewing point
> (4), DSA keys need to be bound to one specific digest algorithm.
> Accordingly I think the right structure is:

> 
>     struct {
>         select (SignatureAlgorithm) {
>             case anonymous: struct { };
>             case rsa:
>                 HashType digestAlgorithm;       // NEW
>                 digitally-signed struct {
>                     opaque hash[Hash.length];
>                 };
>             case dsa:
>                 digitally-signed struct {
>                     opaque sha_hash[20];
>                 };
>             };
>         };
>     } Signature;
> 
> 
> And note that we'll need DigestInfo encoding to protect against hash
> substitution.

I'd prefer a more uniform approach:

    struct {
        opaque signature_algorithm<0..2^16-1>;
        opaque signature_value<0..2^16-1>;
    } Signature;

where signature_algorithm is DER-encoded AlgorithmIdentifier
structure, and signature_value is the actual signature value 
(and for anonymous, both are just zero-length strings).

This would work even in the case of ANSI X9.62 encoded ECDSA 
public keys, where SPKI can list more than one acceptable hash 
algorithm. (If they're all secure, substitution may not be 
a problem; IMHO this is a CA policy issue, and we shouldn't
hardcode this in TLS.)

Best regards,
Pasi

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.