Re: [TLS] TLS v1.2 performance (was Re: TLSv1.2 with DSA client

[Martin Rex <[e-mail]>]

Matt DeMoss wrote:
> 
> Martin Rex <[e-mail]> wrote:
> >
> > The TLS spec should not mess around with PKI and X.509 issues.
> > Negotiation of the algorithm used for the "digitally signed" struct
> > ought to be _completely_ seperate from characteristics of certificates.
> >
> > A TLS extension to convey hints about digital signature algorithms
> > ought to be a fairly black box to TLS, containing a list of
> > ASN.1 AlgIds, and with the semantic of a "hint to the PKI software
> > for selecting the most appropriate certificates", i.e. "MAY" not "MUST".
> 
> This is interesting to me; as a kind of thought experiment do you
> think it would ever be appropriate for TLS to negotiate hash
> algorithms on CRLs or on OCSP responses? It seems unlikely that
> multiple CRLs will be generated with different hashes and that is only
> slightly less true for X.509 certs.

As a black-box TLS extension where apps or the PKI-stack
can exchange hints that the peer could take into account when selecting
adequate certs, crls or ocsp-responses would be fine.



> 
> Does it make more sense for TLS to instead negotiate the version of
> X.509 (or PKIX profile, or other credential) in use and hope some
> future version will provide functionality for a smoother transition?

The most simple approach would be through the use of seperate trust
anchors for seperate algorithm sets.  It would work as is with most
of the installed base of TLS software.  But there are a few PKI diehards
(especially those from the "there can be only one Root" PKIs) that are
fiercly fighting against having to add a few trust anchors
and an 10% additional administrative overhead for a three-digit
number of CAs--they rather want the other 6 billions on the planet
to suffer long and hard with any migration.


>
> I read RFC 5280 to say there can only be one signature per certificate,
> but it isn't hard to imagine having doubly signed certificates in the
> future.


Unlike PKCS7/CMS and PGP keys, which can handle multiple independent
signatures, X.509 was created with insufficient thought on the
security needs of EndEntities.  With X.509, the EndEntities have
zero effective control about what CAs attribute to their identities.


The DANE/keyassurance working group is trying to provide a solution
that this problem can be mitigated for TLS server certificates in
the future (a solution outside of X.509).


I'm actually more concerned about the reluctance of some vendors
to ease a transition.  Why do I need to manually request a patch
like this:  http://support.microsoft.com/kb/968730
(I'm using WinXP 64-bit, which is Windows 2003 under the sheets)

Vendors with digital signatures on software (and timestamps on those
signatures) should not be using sha1 anymore for any of the signatures in
that process, and therefore have a genuine interest in getting SHA256
into all of their platforms and with the very next automatic
software update...


-Martin