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.