On Mon, Mar 09, 2020 at 11:48:40AM -0700, Kathleen Wilson via dev-security-policy wrote: > ==Bad==
This is a *very* long list of bad things. Based on this list alone I think it would be reasonable for Mozilla to reject this application. I'd like to highlight the things that are practically problematic, based on my recent work attempting to revoke certificates for compromised keys. > * 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 > (“highprioritycertificateproblemrep...@e-szigno.hu”, > “revocat...@e-szigno.hu") are found in other sections of some documents. Section 1.5.2 is where I go looking for contact information to revoke a certificate. If it's not there... I'm outta luck. > 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. I like their clarity that they don't accept revocation requests to other addresses, but then not listing any valid addresses does make it tricky. Especially since the previous paragraph gives an e-mail address to contact. On that subject: s4.9.5 of the DV/OV CPS states: > In case of applications sent by electronic mail, the time of arrival is > when the email is received to the dedicated email address > revocat...@e-szigno.hu on the server of the Trust Service Provider. > Emails arriving out of office hours are considered as arrived at the > beginning of the next business day. I don't believe this is in alignment with the BRs, Mozilla Policy, or general expectations around the availability of a CA. Most of the CPSes I've dug into recently make mention of maintaining "24x7x365" availability for accepting and processing problem reports (and, to be fair, I do often get responses from CAs at all hours). "Next business day" processing is woefully inadequate. Rolling back to the beginning of s4.9 of the DV/OV CPS, let's go through it in order. s4.9: > The usage of the private key belonging to the revoked Certificate shall be > eliminated immediately. If possible, the private key belonging to the > revoked Certificate shall be destroyed immediately after revocation. This is a bit odd to see in a CPS. I am assuming there is something in the subscriber agreement that makes this binding on a subscriber. In any event, I, personally, would consider any issuance of a new certificate using the same private key as a revoked certificate to be misissuance (I don't know if Mozilla would feel the same way). s4.9.2 does not allow me, as an Internet Rando who happens to have an unhealthy fascination with collecting published private keys, from requesting revocation. The CPS really must not dissuade third parties from reporting problems with certificates, IMO. s4.9.3, subsection "High-Priority Certificate Problem Report", does not define what constitutes a "high priority" report, but intimates that it involves requests where law enforcement may need to become involved. If you follow enough links, you get to a page that suggests that key compromise may be considered a "high priority" report, however were I to be looking at this CPS to find a way to report a key compromise, I would not consider using this "high priority" channel, based on the information in this CPS. Based on the above points, and the lengthy set of "bad" points previously identified by Wayne, I would ask Mozilla to reject this application. - Matt _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
