Re: [TLS] Possible TLS 1.3 erratum

[Ryan Sleevi <[e-mail]>]

On Tue, Jul 20, 2021 at 12:17 PM Peter Gutmann <[e-mail]>
wrote:

> Is that purely to parse PSS in X.509, or for the overall PSS
> implementation?
>

The overall PSS implementation. Parsing PSS w/o an implementation is
sillypants.

Like most modern libraries, NSS is decoupled through various concerns. For
example, one layer deals with parsing the DER and extracting a higher-level
symbolic value specific to the API.


> I know PSS is a dog's breakfast of arbitrary parameters and values, but
> I'm a
> bit suspicious of that line count just to to process the 'Parameters'
> structure, particularly since it's shared with OAEP so already present if
> you
> support OAEP.
>

Eh, say that again? PSS uses RSASSA-PSS-Params and that's a distinct type
than RSAES-OAEP-Params - saltLength/TrailerField vs pSourceAlgorithm.

But most APIs abstract things so folks aren't dealing directly in DER, but
in whatever language-specific representation with type-safety - e.g. a C
struct/Java class/etc

Or are you supporting every single possible corner case and weird option
> rather than just { SHA-2, MGF1, SHA-2, $SHA2-blocksize }?
>

This is 100% part of the problem with PSS - that the parameters have
multiple combinations, rather than being either empty (encapsulated by the
OID to represent the combination) or being memcmp()able. However, both
cryptographic libraries and PKI libraries tend to deal with the abstract
specification.


> And that's exactly the point I'm making, the standard currently encodes
> low-
> level internal details of the PKI implementation into the TLS
> implementation.
>

Others have pointed out, this was already true with prior versions of TLS
and signature_algorithms reflecting both the TLS parameters and the PKI
parameters. The only distinction here is TLS 1.3 allows them to be treated
separately - since from the TLS point of view, the PKI is *mostly* an
opaque black box. I say *mostly*, because there is the TLS-level constraint
on the keyUsage of the identity certificate.


> Unless you're using one library to do it all, the TLS layer has no idea
> what
> OID the PKI layer is using to identify an RSA key in a certificate, and so
> it
> has no idea whether it should be saying rsa_pss_rsae or rsa_pss_pss because
> the PKI layer just presents a certificate with an RSA key.
>

No, this isn't really correct either. As mentioned above, since the first
version of TLS, there has been some coupling to the subject certificate
(the server certificate on the server, the client certificate for the
client). The server certificate's keyUsage has long affected the available
ciphersuites a TLS server can successfully negotiate - e.g. whether you're
using an ephemeral key exchange or not - and the subject key has equally
had an impact - e.g. you're not going to negotiate RSA with an EC key, full
stop.

So there's inherently a coupling at the subject certificate, but the
remainder, the certificate path building and verification part, is largely
left as an exercise to the reader. Netscape did this with SSL the IANA IPRA
of RFC 1422 never came about (and for good reason). It was left as a "TBD /
implementation defined" about the policy side, other than the requirements
on the leaf.

TLS 1.3 simply continues this abstraction. The TLS library knows what it
supports at the TLS layer, and still has to be able to parse certificates
and keys (but only its identity certificate), and can leave the
caller/consumer to provide the parameters about what its PKI library
supports.


> All of this is currently hidden by the fact that you can't get PSS-OID
> certs
> from any public CA that I know of


Yes, they're generally forbidden by browser policy, to avoid the
combinatorial compatibility explosion.


> so everyone can just hardcode rsa_pss_rsae
> everywhere and ignore the issue, but at some point some CA may accidentally
> issue a PSS-OID cert and then who knows what'll happen.


I'm not sure why you're posing it as "unknown" what will happen,
considering it's well-defined.