On Tue, Dec 11, 2018 at 6:58 AM Daniel Kahn Gillmor <d...@fifthhorseman.net> wrote:
> On Sun 2018-12-09 18:35:20 +0100, Kurt Roeckx wrote: > > On Wed, Dec 05, 2018 at 07:07:30AM +0300, Daniel Kahn Gillmor wrote: > >> One mitigating factor of the ETSI standard, i suppose, is that the > >> CABForum's Baseline Requirements forbid issuance of a certificate with > >> any subjectAltName other than dNSName or iPAddress, so otherName looks > >> like it must not be issued by standard public CAs. > >> > >> top of p. 44 of > https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.1.pdf > >> > >> Has anyone set up tools to monitor the CT logs for such a sAN to see > >> whether that element of the BR is being honored? > > > > All the linters will give an error about that, see for instance: > > https://crt.sh/?id=1009623020&opt=x509lint,cablint,zlint > > right, so what is to be done about that, when some of these CAs are > clearly violating the BRs? Transparency is only as useful as the > actions we can take once violations are uncovered. Unactionable > transparency just sounds like despair to me. So what's the action? The same as it is for any misissuance: 1) Report to the CA’s problem reporting mechanism. The Baseline Requirements require they provide one in Section 1.5.2 of their CPS (BRs Section 4.9.3). The CA is obligated to revoke such certificates and, according to various root policies, report and/or disclose to the root programs they participate in or publicly. If you are unsatisfied with the answer you get from the CA, or want to ensure greater transparency, you can/should also 2) Report to any root programs that trust those CAs. The example from Kurt is from a CA that is ONLY trusted by Microsoft, and which other programs have, sometimes explicitly, declined to trust. If CAs are violating the contractual or public requirements of Microsoft’s root program, such as the one demonstrated (although notably, it is NOT displaying the use of this ETSI MITM extension), then that is an enforcement action for Microsoft, or something for their customers to respond to if Microsoft is shipping insecure CAs to them. Your best-best-case is that publicly trusted CAs never issue such certificates. Your worst-best-case is that the CA has to revoke within 24 hours/5 days of issuance, and that the root program takes the violation into consideration when evaluating whether to trust that CA. Your worst-worst case is that the CA ignores the revocation requirements, as they did the issuance requirements, and that root programs that trust those CAs fail to take action to ensure consistency among the CAs they trust and with the requirements.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
