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

Re: [TLS] Signature Hash Agility



At Thu, 19 Jul 2007 15:22:56 +0300,
<Pasi.Eronen at nokia.com> wrote:
> 
> 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.)

I'm OK with a uniform type, but I think a HashType is what's
appropriate here. OIDs don't seem like the TLS way...

-Ekr

_______________________________________________
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.