On Tue, Jul 20, 2021 at 12:17 PM Peter Gutmann <pgut...@cs.auckland.ac.nz> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls