On Tue, Jul 20, 2021 at 10:19 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
> Hubert Kario <hka...@redhat.com> writes: > > >I suggest you go back to the RFCs and check exactly what is needed for > proper > >handling of RSA-PSS Subject Public Key type in X.509. Specifically when > the > >"parameters" field is present. > > Looking at the code I'm using, it's four lines of extra code for PSS when > reading sigs and four lines extra when writing (OK, technically seven if > you > include the "if" statement and curly braces lines). > I'm very happy for you. I think other implementers' experiences vastly differ from your experience, and I hope we can agree that both are valid of consideration. For example, the NSS library used by Mozilla has well exceeded a thousand lines of code so far. I'm sure a thousand lines may not seem like much, in the grand scheme of things, but not every line is "free or easy" - some lines are harder to change, and reason about, due to the security implications. For NSS, this is in part due to its layering design based on PKCS#11 and its abstraction interfaces for certificates and verification. It's also partly because as a security-critical library that affects millions of users, a different standard is applied than might be applied a hobbyist project. 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". From browsers to mobile devices to the server room, it's not uncommon for TLS to be implemented by one layer or library, while certificate verification to be handled by another. They may share a cryptographic library (e.g. using NSS or JSSE), or they may not (e.g. Chrome, which integrates with both BoringSSL and the OS libraries). As such, it's not uncommon for there to be distinction in terms of capabilities, whether due to abstractions in use or capabilities of the library in use.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
