Re: Request to Include Microsec e-Szigno Root CA 2017 and to EV-enable Microsec e-Szigno Root CA 2009
Dear Sándor, I have a couple of follow-up questions for Microsec. There were some responses during the recent public discussion in which Microsec indicated it would update its CPS(es). When do you anticipate that this will occur? Also, it is also unclear from the quoted thread below whether such updates will include additions to section 1.5.2 as required by Section 4.9.3 of the Baseline Requirements. Could you please clarify if and when section 1.5.2 will be updated? Thanks. Sincerely yours, Ben Wilson Mozilla Root Program - BR section 4.9.3 requires CPS section 1.5.2 to contain instructions for reporting an issue such as key compromise to the CA. The Microsec CPS’ only state that questions related to the policy may be reported via the info in that section, and other email addresses (“highpriority...@e-szigno.hu”, “revoc...@e-szigno.hu") are found in other sections of some documents. Section 4.9.5 then states that revocation requests are only accepted at the address listed in section 1.2, but there is no email address in this section. The CPS of Microsec is structured according to the requirement of RFC3647. This also required by the CABF BR in section 2.2. According to RFC3647 the Section 1.5 is for the policy administration and section 1.5.2 defines the contact person who is responsible for maintaining the CPS. Section 4.9.3 of the CPS contains detailed information about the possibilities of revocation request submission. Section 1.3.1 contains the email addresses, where revocation request can be sent (mentioning section 1.2 is an editorial mistake, it will be corrected in the next version of the CPS). Section 4.9.3 contains also a subsection which describes the High-Priority Certificate Problem Report mechanism. More detailed information can be found on our website on the given link. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GTS - OCSP serving issue 2020-04-09
On 17/04/2020 14:22, Nick Lamb via dev-security-policy wrote: GOOD means_at least_ the good CertStatus (also 0) in OCSP. We'll see why in a moment. Fair enough. That's what I thought - so holding onto the last successful OCSP report you have, even if you get exception status codes thereafter is a good way forward. I think that's reasonable. I'm just less sure that you should be treating a well formed 'revoked' response as something which can be ignored until the current 'good' OCSP response expires. [Note my carefully chosen weasel words like 'well formed', which also entails stuff like proper timestamp checking etc, etc]. Ryan's writeup calls out the revoked situation under the heading of 'make sure it is something the client will accept' - if the client understands OCSP responses at all, it needs to understand revoked, surely? But why? We are us, why would we want to announce that our certificate is revoked? What possible benefit could accrue to us from choosing to do this? Because it places you (a good actor) in compliance with your subscriber agreement? Just as an example, some text in a few commonly used CA Subscriber Agreements have subscriber obligations like "cease all use of the Certificate and its Private Key upon expiration or revocation of the Certificate" or "Subscriber shall promptly cease using a Certificate and its associated Private Key" (under the section for revocation). Presumably failure to adhere to that agreement could place you in some contractual jeopardy? So, following from your response, I think that, indeed - shutting down the site until a replacement key/cert is deployed would be the 'right' thing to do, rather than advertise a revoked response. The difference being that shutting down is (usually) a manual step, whereas stapling the most recent valid response from the CA (good or revoked) is probably an automated step. Regards, Neil ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: GTS - OCSP serving issue 2020-04-09
On Thu, 16 Apr 2020 13:56:34 +0100 Neil Dunbar via dev-security-policy wrote: > On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote: > For the avoidance of doubt (and my own poor brain) - does 'GOOD' here > mean OCSP status code 'successful' (0) AND returning a 'good' status > for the certificate, or does it just mean status code 'successful'? > The GTS case here was returning OCSP exception status 'unauthorized' > (6). GOOD means _at least_ the good CertStatus (also 0) in OCSP. We'll see why in a moment. Ryan provides a considerably longer list of stupid things that might go wrong in item (2) from https://gist.github.com/sleevi/5efe9ef98961ecfb4da8 You should consider all of them reasons the answer shouldn't replace an existing GOOD answer you have. > I would have thought that an OCSP-stapling implementation which got > an OCSP status code 'successful' (0) with a 'revoked' status for the > certificate would want to pass that on to the client, replacing any > prior OCSP successful/status-good report, whether that prior report > was still valid. But why? We are us, why would we want to announce that our certificate is revoked? What possible benefit could accrue to us from choosing to do this? Remember we cannot choose the behaviour of an adversary. So if we choose to tell clients our certificate is revoked, but an adversary asserts their copy is still good, clients will continue to talk to the adversary which is almost certainly a worse outcome. If your model of TLS still looks like early SSL, with implicit RSA authentication then I can see that if you squint advertising your own revocation isn't completely stupid. Maybe the revocation means an adversary knows our private key, and so in continuing to talk to clients with this key we make things worse, we should admit it's revoked instead. I'd argue that if this was a scenario you care about the right thing is for the server to shut down instead, not staple revoked responses. But anyway sites which actually care about security should never use implicit authentication (and it doesn't exist in TLS 1.3). As a result there is zero risk from pressing on, you are definitely you, the only question is whether you can continue to convince clients that this is so, and stapling a non-GOOD answer will never help you do that so it's never the correct thing to do. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
