I think it's reasonable to consider mistakes in StartCom's new PKI of this nature to be a part of "continuing pattern of behavior" from their previous PKI, and not something which should be considered in isolation. In that context, I'm not sure comparisons with other CAs which were "first time offenders", and which were given an opportunity to clean up, make sense.
Alex On Thu, Aug 3, 2017 at 4:43 PM, Kathleen Wilson via dev-security-policy < [email protected]> wrote: > On Thursday, August 3, 2017 at 9:49:41 AM UTC-7, Jonathan Rudenberg wrote: > > Even absent the BR-violating certificates and disclosure timeline, I > believe this cross-sign is problematic because it appears to circumvent the > prerequisites and process described in https://bugzilla.mozilla.org/ > show_bug.cgi?id=1311832 for StartCom’s application for re-inclusion into > the Mozilla root store. It’s not clear to me what the point of those > requirements is if they can be avoided by obtaining cross-signatures from > other CAs that are currently trusted by Mozilla. > > It is common practice for a CA to get cross-signed by a currently-included > CA, so their cert chain is trusted while they are going through Mozilla's > long inclusion process. This is OK, as long as the currently-included CA > ensures that the subCA follows Mozilla's Root Store Policy. > See section 5.3 of > https://www.mozilla.org/en-US/about/governance/policies/ > security-group/certs/policy/ > > I would have a problem if Certinomis cross-signed with the old StartCom > roots for which we do not trust certs issued after October 2016. In my > opinion, that would be grounds for removing Certinomis' roots. > > However, I think it is fine for Certinomis to cross-sign with new StartCom > subCA certs, as long as Certinomis ensures that Mozilla's Root Store Policy > is being followed. > > > > As far as the misissued certificates are concerned, here are a couple > points to consider: > > > > 1) Many of the certificates are improperly validated “test” > certificates, a practice that is extremely problematic and indicates a lack > of or circumvention of technical controls. > > > Yes, this is problematic. But other CAs have also had this problem, and > for the other CAs we have worked with them to ensure the practice is > stopped, tools/process put in place to prevent it in the future, > problematic certs revoked, etc. But this type of mis-issuance has not yet > been considered grounds for adding the relevant intermediate cert to OneCRL. > > > > 2) StartCom's systems are apparently new, but they have failed to > correctly implement simple aspects of the certificate profile such as > keyUsage bits and character encodings. These issues are trivially detected > by running tools like certlint and should have been caught well before the > system made it into production. > > > This is the part that particularly concerns me. I would expect StartCom to > be on their best behavior and setting up an exemplary PKI. These types of > mistakes should not be happening. This is the main reason I am considering > adding the two intermediate certs to OneCRL and telling the CA to start > over, and make sure they do it right this time. > > Thanks, > Kathleen > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
