Ryan Sleevi <ryan-ietf...@sleevi.com> writes:
>For example, the NSS library used by Mozilla has well exceeded a thousand
>lines of code so far.
Is that purely to parse PSS in X.509, or for the overall PSS implementation?
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.
Or are you supporting every single possible corner case and weird option
rather than just { SHA-2, MGF1, SHA-2, $SHA2-blocksize }?
>For browsers like Chrome, used by over a billion users, there are indeed
>practical concerns regarding the separation between the TLS layers and the
>certificate layer. The "classic" late-90s view of "one library to do it all"
>(TLS and PKI) is actually not that common in industry, at least not those
>being used "at internet scale".
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.
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.
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 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.
For every single TLS implementation out there.
Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
