For this particular incident, I would like to know why the CA didn’t review the 
profile before signing the root. It seems like a flaw in the process in the key 
ceremony process not to go through a checklist with the profile and ensure each 
field complies with the current version of BRs. 

Question on browser behavior - will revocation of the cross essentially result 
in revocation of root 2 since the date is newer? Anyone distributing that 
cross, will basically see the root as revoked unless they have the root 
embedded by then, right?

-----Original Message-----
From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On 
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, October 7, 2019 10:21 AM
To: r...@sleevi.com
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: CAs cross-signing roots whose subjects don't comply with the BRs

Yeah - I like the visibility here since I know I often forget to post the 
incident to the Mozilla list as well as post the bug. 

IMO - it's up to the CA to decide if they want to sign something in violation 
of the BRs and then it's up the browsers on what the action taken in response 
is. I acknowledge this is somewhat a non-answer, but I think if the CA 
discloses why they are signing something, works with the community to decide 
the action taken is better than the alternative, accepts the risk to the audit, 
then they should do it, assuming the risk. The BRs are pretty rigid so there 
may be circumstances that merit violation of the requirements, but that 
violation should only be done with as much transparency as possible and 
considering all the positions. 

For example, suppose a root was created before a rule went into place and the 
root needs to be renewed for some reason. If the root was compliant before 
creation and modifying the profile would break something with the root, then 
there's a good argument that you shouldn't modify the root during the resign. 
That assumes the reasons are discussed here and alternatives are explored 
fully.  This should then be documented (including the reasons) in an incident 
report and the subsequent audit. 

Tl;dr - No, CAs shouldn't sign things that violate the BRs, even roots. But I 
could see there being reasons for the CA to do so.

(And I haven't scanned CT to discover if it is us. Crossing my fingers it's not 
😊. If I don't scan, it's like a terrible version of Christmas.)

-----Original Message-----
From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, October 7, 2019 10:07 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: CAs cross-signing roots whose subjects don't comply with the BRs

On Mon, Oct 7, 2019 at 11:54 AM Jeremy Rowley <jeremy.row...@digicert.com>
wrote:

> Are both roots trusted in the Mozilla root store? If so, could you say 
> that Mozilla has approved of the root not-withstanding the non-compliance?
> If root 2 did go through the public review process and had the public 
> look at the certificate and still got embedded, then Mozilla perhaps 
> signed off on the root.
>

Good question!

Yes, it turns out that a version of this cross-sign is included, and while 
there was a public discussion phase, this non-compliance was not detected 
during the inclusion request nor part of the discussion. In fact, there were 
zero comments during the public discussion phase.


> That said, I don't personally see the harm in incident reports (other 
> than the fact that they can be used for negative marketing). They are 
> there for documenting issues and making the public aware of issues.
> Like qualified audits, they don't necessarily mean something terrible 
> since they represent a disclosure/record of some kind. Even if the 
> incident report is open, discussed, and closed pretty quickly, then 
> you end up with an a record that can be pointed to.  Filing more 
> incident report (as long as they are different issues) is a good thing 
> as it gives extra transparency in the CA's operations that is easily 
> discoverable and catalogable. Makes data analytics easier and you can 
> go back through the incidents to see how things are changing with the CA.
>

Well, the reason I raised it here, rather than as an incident, was to try and 
nail down the expectations here. For example, would it be better to have that 
discussion on the incident, with "Foo" arguing "You approved it, ergo it's not 
a violation to cross-sign it"? Or would it be better to have visibility here, 
perhaps in the abstract (even if it is trivial to scan CT and figure out which 
CA I'm talking about), if only to get folks expectations here on whether or not 
new certificates should be signed that violate the BRs?
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to