Subject: [TLS] rfc4366-bis-03 Discuss #2: hash alg. agility for TrustedCA?

From: Alfred Hönes <[email-masked]>
Date: Tue, 21 Oct 2008 22:00:42 +0200 (MESZ)

(A)  hash algorithm agility for the Trusted CA Keys TLS extension

Section 5 of the rfc4366-bis draft contains the following
TLS presentation language definition (from RFC 4366):

---------------------------snip----------------------
      struct {
          TrustedAuthority trusted_authorities_list<0..2^16-1>;
      } TrustedAuthorities;

      struct {
          IdentifierType identifier_type;
          select (identifier_type) {
!             case pre_agreed: struct {};
!             case key_sha1_hash: SHA1Hash;
!             case x509_name: DistinguishedName;
!             case cert_sha1_hash: SHA1Hash;
          } identifier;
      } TrustedAuthority;

      enum {
!         pre_agreed(0), key_sha1_hash(1), x509_name(2),
!         cert_sha1_hash(3), (255)
      } IdentifierType;

      opaque DistinguishedName<1..2^16-1>;
---------------------------snip----------------------

where SHA1Hash is borrowed form Section 5:

---------------------------snip----------------------
      opaque SHA1Hash[20];
---------------------------snip----------------------

This WG is tasked by the IESG & IAB to introduce crypto algorithm
agility into the protocols it supports, whereas the above definition
is still restricted to SHA-1 only.

Therefore, the questions arise:

-  Should the enum IdentifierType be extended with new values
   indicating other hashes for keys and certificates?

-  If yes, adding only SHA-256 (in the spirit of TLS v1.2),
   or adding more variants?

Any opinions?  Further considerations?

(B)  Non-uniqueness of x509_name in Trusted CA Keys TLS extension

The 3rd-to-last paragraph of Section 6 in the -03 version
of the rfc4366-bis draft states:

!  Note also that it is possible that a key hash or a Distinguished Name
!  alone may not uniquely identify a certificate issuer (for example, if
!  a particular CA has multiple key pairs). However, here we assume this
!  is the case following the use of Distinguished Names to identify
!  certificate issuers in TLS.

It seems rather unlikely that this non-uniqueness happens for
a key hash.

But in the course of rekeying or when multiple signature algorithms
(RSA/DSA/ECDSA) are supported by a CA, this non-uniqueness could be
expected to happen rather commonly for x509_name.

-  Is the above quoted assumption still justified?

-  If not, should another common identifier type,
   IssuerAndSerialNumber,
   be introduced to help avoid the ambiguity?
 -or-
-  Does everybody use hashes anyway, such that deprecating
   the x509_name variant might be considered ?

Any opinions?  Further considerations?

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Oct 2008 10:56:01 +0200

> It seems rather unlikely that this non-uniqueness happens for

Can't you have multiple CA certificates for the same key?

/Simon

---

From: Dean Anderson <[email-masked]>
Date: Wed, 22 Oct 2008 21:12:52 -0400 (EDT)

> Can't you have multiple CA certificates for the same key?

You _can_ have multiple key pairs, but knowledge of any key pair allows
one to calculate P and Q, so having multiple key pairs for the same
modulus is a "bad idea", because with one pair one can calculate any
other pair given one of the other pair.  I believe that both Schnier's
Applied Cryptography, 2nd and the CRC Handbook of Applied Cryptography
recommend against this practice.  The CRC Handbook gives the method to 
calculate P and Q given the public and private keys.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 22 Oct 2008 19:45:34 -0700

At Wed, 22 Oct 2008 21:12:52 -0400 (EDT),
> calculate P and Q given the public and private keys.

The question is whether you can have multiple CA certificates with
*identical* keys, not multiple certificates with the same modulus but
different e/d. The answer to this is "yes". If you want to uniquely
identify a cert you shoul duse a hash of the cert.

-Ekr

---

From: <[email-masked]>
Date: Thu, 23 Oct 2008 15:27:43 +0300

I don't think having hash agility in this particular case is 
needed -- this use doesn't require a cryptographically
strong hash function (even a CRC would do).

Best regards,
Pasi 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Alfred HÎnes
> Sent: 21 October, 2008 23:01
> To: [email-masked]
> Subject: [TLS] rfc4366-bis-03 Discuss #2: hash alg. agility 
> for TrustedCA?
>

---

From: Dean Anderson <[email-masked]>
Date: Thu, 23 Oct 2008 11:42:04 -0400 (EDT)

> > > > !  certificate issuers in TLS.

[...]

> identify a cert you shoul duse a hash of the cert.

Ok. I follow this; the draft should really say that. So, just replace:

  However, here we assume this is the case following the use of
  Distinguished Names to identify certificate issuers in TLS.

with 

  Use a hash of the certificate to uniquely identify a certificate.

Of course, there could still be a hash collision, so the whole
certificate would need to be compared.  But that isn't really enough,
because ASN.1 encoders can produce ambiguous encodings of the same data.  
One really needs to compare the decoded ASN.1 data to see if it is the
same on two separate certificates.

		--Dean