On Wed, Apr 26, 2017 at 03:23:57PM +0200, Martin Rex wrote:
>
> Signatures on certificates are created by CAs, rather than TLS endpoints,
> so any implementation that uses TLS protocol parameters (about TLS signature
> algorithms) for more than a mere cert selection hint, is actively creating
> interop problems while providing *NO* value. Many TLS peers will have
> just one suitable certificate anyway, so not even looking at certificate
> signatures will be the easiest to implement, most robust and perfectly secure
> behaviour anyway.
What my implementation does with certificate signatures:
- There actually are signature algorithms with no known TLS code, e.g.
ECDSA-SHA3 signatures. These are known but can not be advertised.
- The built-in server-side certificate selection code never selects
certificate containing algorithm client didn't advertise.
- The server side certificate chain checking interlocks on unknown
signature algorithms, but not unadvertised signature algorithms. So
custom certificate selector can overrule the client advertisment, but
not known algorithm check.
- On client side, all known algorithms (other than PKCS#1/SHA-1, which
is treated specially) are treated as valid for certificates. Advertised
or not. All others are just ignored (which violates a MUST in spec)
and path building never builds through those..
- Regarding RSA-PSS, only the 3 variants that TLS defines are supported).
> The issue with RSA-PSS digital signatures is that they were defined
> with additional (unnecessary) parameters that are encoded (=hidden) in the
> ASN.1 AlgorithmIdentifier, and that are therefore unspecified when
> RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1
> AlgorithmIdentifier.
TLS 1.3 specifies what values those parameters have for various
SignatureSchemes.
> The additional, unnecessary parameters are "saltLen" and
> "MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction
> (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash).
Also specified.
> In theory there is another additional, unnecessary parameter "TrailerField",
> which appears in the ASN.1 AlgorithmIdentifier parameter list (and in the
> XMLdsig encoding for RSA-PSS), but PKCS#1 v2.1 (rfc3447) essentially
> hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc.
So this also counts as specified.
>
> The definition of "implied" RSA-PSS parameters applies only to the
> "digitally-signed" signature blobs using inside the TLS protocol
> because these do not come with an ASN.1 AlgorithmIdentifier tag.
> The implied RSA-PSS paramters for TLS' digitally-signed are unrelated
> to RSA-PSS signatures on certificates (certificates come with explicit
> RSA-PSS parameters encoded in an ASN.1 AlgorithmIdentifer):
>
> Certificate ::= SEQUENCE {
> tbsCertificate TBSCertificate,
> signatureAlgorithm AlgorithmIdentifier,
> signatureValue BIT STRING }
>
> The original RSA-PSS AlgorithmIdentifer specification also defines
> a hierarchical policy concept, that is supposed to limit the kinds
> of signatures that can be created (verified) with a so-tagged public
> RSA key, and this policy is supposed to work/apply from the RootCA cert
> *downwards* to the leaf / end-entity cert.
I don't think it appiles that way, only per-key.
ExtendedKeyUsage is *not* supposed to be hierarchial, but doesn't
prevent many libraries from handling it that way.
> It seems silly trying to apply implied RSA-PSS parameter selections
> from the digitally-signed TLS protocol transform to the signature
> on the TLS end-entity cert (or worse, even to certs up the cert chain),
> because that would be the wrong/invalid direction.
The SignatureScheme selections only mean those schemes are supported,
not that other RSA-PSS schemes can't be supported in CA signatures
(however, there is no way to advertise those).
> What should be spelled out, whether and how any RSA-PSS policy in the
> subjectPublicKeyInfo AlgorithmIdentifier of the end-entity certificate
> interacts with implied RSA-PSS parameters used by the TLS digitally-signed
> transform. In any case, the decision whether to accept a certificate
> should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender.
AFAIK, the only place there is any impiled interaction is when the end-
entity key is RSA-PSS-only. And there the rules are usual matching rules
versus the key.
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
