@Florian The document is about the SSL 2.0 security deficiencies, particularly the ones that brought its prohibition. The solutions to these deficiencies might also have their own problems, as it's often the case in security related topics which look like a never-ending debate (a problem, a solution, a new problem), and they would logically be discussed in their own threads or we would easily make anachronistic comments. The mitigation of a root authority has a huge impact, and requires time to solve, that's what said at that time, although it happened much later to some issuers. In practice we see that direct signed certificates for Internet use were abandoned, without anyone returning back to them. Also, the HSMs are getting more widely used, and it gives more protection to the keying material (which is an answer to the "overexposed keys").
@Ryan Thanks. There's also that link https://www.ietf.org/blog/iesg-processing-rfc-errata-ietf-stream/ which is almost saying the same. But at the same time RFC6176 is not exactly a protocol description, it's a limited update to existing protocols that had warned us this update would be published one day. Submitting an update for a non technical part of this RFC doesn't make much sense too, maybe no more than a rejected errata. Le mar. 16 oct. 2018 à 08:12, Florian Weimer <f...@deneb.enyo.de> a écrit : > * RFC Errata System: > > > Corrected Text > > -------------- > > > o The root certificate authority keys are overexposed. The server > > sends only one certificate signed by a root certificate authority, > > which means a frequent use of this authority keys for signing new > > certificates. This use can lead to key loss and the compromise of > > all certificates previously signed including the root certificate.. > > > > Notes > > ----- > > Adding a deficiency. > > Recent history showed that well-known authorities could loose their keys > and it had a wide impact on security. > > SSL 2.0 limits the certificate handshake message to one single > certificate, thus making it impossible to send a certificate chain. > > A certificate chain doesn't completely prevent key loss, but it gives > more protection to the root certificate keys which can be stored and hidden > until we need them again, which is much less often than without chaining. > > > > > > > > --VERIFIER NOTES-- > > This isn't an error in the original document. It's new text you want > to add. > > I think it's also historically incorrect. More security problems were > caused by the ability to introduce arbitrary intermediate certificates > by CAs than by too many direct signing operations with a root CA key. > At least for web use, the original model (which does not allow > delegation of trust on the CA side) might actually have been more > approriate. (On the RA side, delegation is of course technically > possible under any model, and it had its share of problems, too.) >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
