RE: [TLS] TLS 1.2 and hash agility for signatures

Bodo Moeller wrote:

> I guess it's best to include a ClientCertificateType field into the
> client's Certificate message (not the CertificateVerify message since
> some methods don't use it):

Hmmm... why do we need ClientCertificateType in the Certificate 
message, if we also add the algorithm identifier to Signature type 
(also for RSA)?

<snip>
> You are right that including an algorithm identifier field into the
> Signature type make sense.  I'd prefer to keep this optional since
> it's not always needed, since for example the "rsa" case of Signature
> really means RSA PKCS#1 v1.5, which does not need the algorithm
> identifier.  

In today's meeting somebody pointed out that we probably want the
identifier for RSA PKCS# v1.5 as well, since some crypto libraries
export an API that matches the "signature verification operation"
described in RFC 3447 Section 8.2.2. And there you actually need to
know which hash algorithm was used before you start verifying the
signature...

> Any other use of RSA signatures, such as PSS, would require new 
> ciphersuites and new "ClientCertificateType" values (sort
> of a misnomer, since distinct client authentication methods don't
> necessarily imply distinct X.509 certificates ...), or possibly other
> (extension-based) ways of negotiating the use of PSS or whatever.  

I agree, PSS server certificates would be best handled by new cipher
suites, and PSS client certificates with new client certificate types.

<snip>
> > If we use the AlgorithmIdentifier structure in the Signature,
> > would that also work for the cert_hash_types extension? (Which,
> > as you point, could be really called "signature_hash_types" 
> > since it also covers signatures outside certs.)
> 
> You mean, to indicate hash algorithms in this case (not signature
> algorithms)?  I'd prefer using a brief list of identifiers defined in
> the TLS specification (which is exactly what HashType is now), to be
> interpreted as a hint and not as a complete description of what the
> party in question can handle.
>
> (In some cases, depending on the software design, we might have
> implementations that can handle certain hash functions for some
> signature algorithms but not for others.  We can't put all such
> details into a HashType list.  Possibly we could cope with this by
> using a list of *signature* AlgorithmIdentifiers, but such a list
> easily could become very huge, and still wouldn't solve all problems
> related to signature and certificate verification.  

I was thinking about signature algorithm identifiers; but I do agree
that the list could easily get quite long. 

Best regards,
Pasi

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