I don’t think that’s entirely accurate. People like clear guidelines on what will happen if they do x, y, or z. This applies to both revocation and distrust. Historically, there’s times when a CA must revoke the certs and times where the browsers don’t require revocation. This leads to confusion about the likely outcome of each mis-issuance. Trying to define the different categories of misissuance is about trying to make sense of why some CAs must revoke all impacted certs, some CAs are distrusted, and some CAs have more remedial action plan. Of course, all mis-issuance is bad as it illustrates a gap in the CAs process or procedures. However, the browser action in response seems to fall into various categories.
The better definition of misissuance and expected action is probably simpler. Based on watching the various mis-issuances (including our own), the general framework is more along the lines of: 1. Disregard for the guidelines or unwillingness to follow the browser policies = Distrust 2. Impacts security of a website = Revoke 3. Doesn’t impact security but a violation of the BRs = Possible revoke but depends on discussions with the browser and public From: Ryan Sleevi <r...@sleevi.com> Sent: Saturday, July 28, 2018 8:25 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Jakob Bohm <jb-mozi...@wisemo.com>; Tim Hollebeek <tim.holleb...@digicert.com>; mozilla-dev-security-pol...@lists.mozilla.org; r...@sleevi.com Subject: Re: Possible violation of CAA by nazwa.pl On Sat, Jul 28, 2018 at 2:17 PM Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > wrote: I think the desire to categorize these is more to make sense of where the distrust line is. No one wants to end up on the same boat as Symantec, and there aren't clear guidelines on how to prevent that from happening to a CA. I don’t think it’s that cut and dry. Everything enumerated highlights a failure of process - whether that failure was technical or procedural is far less important to the frequency, detection, and remediation of those failures. The expectation is for the CA to design their systems in a way to prevent as many human failures as possible - and there’s little excuse for the technical ones - while also having robust systems in place to detect and remediate. The hidden thread in this is less about CAs being distrusted, and more about finding reasons to not revoke certs - as if some failures are less than revocation worthy. Yet that’s flossing over the largest systemic issue in our industry, which is the lack of certificate agility (in issuance or replacement). Requiring revocation acknowledges that our end state should be the old cert is replaced transparently by the new cert and no systems break - and any difficulty in that either rests with the CA for not investing enough in meaningful systems (automatable validation like those based on DNS, interoperable automated issuance protocols like ACME), or on the Subscriber for not investing in automation. Framing it as somehow being about the Browser reaction is thus incorrect - ANY single instance of misissuance could be worthy of distrust, as could a sustained pattern. Browsers are only going to get better at managing that impact to their users, so both CAs need to get better preventing and Subscribers need to take advantage of the better automation solutions. Pretty much every CA mis-issues at some point on an infinite timeline, and the lack of certainty on browser reaction to the mis-issuance makes it hard to determine the best corrective course of action should be. Obviously, public discussion on issues as they happen is the best way to figure that out, but explaining to management that the consequences of various misissuances could range from root removal to a simple apology, depending on the browser, is pretty difficult. If you follow the list closely, the levels of mis-issuance are a lot more clear. For CAs that don’t' follow as closely, it can be a lot scarier. -----Original Message----- From: dev-security-policy <dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org <mailto:digicert....@lists.mozilla.org> > On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, July 27, 2018 8:01 PM To: Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > Cc: mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Jakob Bohm <jb-mozi...@wisemo.com <mailto:jb-mozi...@wisemo.com> > Subject: Re: Possible violation of CAA by nazwa.pl <http://nazwa.pl> I disagree that a series of categories is good or helpful to the community. I think the framing is generally adopted by CAs that want to see shades of gray in non-compliance, in order to downplay risk or downplay their lack of compliance. As to the Forum, browsers have tried multiple times to introduce definitions. Gerv had previously supported a single definition for any matter of non-compliance, in order to appropriately and adequately inform CAs about expectations, but CAs were still opposed. By focusing on that singular matter, ontologies can be avoided, as can the inevitable disagreements about impact and consequence that detract from a more meaningful focus on action and remediation. On Sat, Jul 28, 2018 at 4:39 AM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: > I agree. > > I've actually thought about adding definitions of categories of > misissuance to the BRs before. Some of the requirements like > revocation are really hard to write and understand if you don't first > categorize all the misissuance use cases, many of which are very, very > different. And just when I think I have a reasonable ontology of them > in my head ... someone usually goes and invents a new one. > > Despite how much people like to talk about it, misissuance isn't a > defined term anywhere, AFAIK. It can lead to a lot confusing > discussions, even among experts at the CA/Browser Forum. > > -Tim > > > -----Original Message----- > > From: dev-security-policy <dev-security-policy- > > bounces+tim.hollebeek=digicert....@lists.mozilla.org > > <mailto:digicert....@lists.mozilla.org> > On Behalf Of > > bounces+Jakob > > Bohm via dev-security-policy > > Sent: Friday, July 27, 2018 2:46 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > <mailto:mozilla-dev-security-pol...@lists.mozilla.org> > > Subject: Re: Possible violation of CAA by nazwa.pl <http://nazwa.pl> > > > > On 26/07/2018 23:04, Matthew Hardeman wrote: > > > On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via > > > dev-security-policy < dev-security-policy@lists.mozilla.org > > > <mailto:dev-security-policy@lists.mozilla.org> > wrote: > > > > > >> > > >>> The party actually running the authoritative DNS servers is in > > >>> control > > >> of the domain. > > >> > > >> I'm not sure I agree. They can control the domain, but they are > > >> supposed to be subordinate of the domain owner. If they did > > >> something without the owner consent/approval, it really looks > > >> like a domain > hijacking. > > > > > > > > > But the agreement under which they're supposed to be subordinate > > > to the domain owner is a private matter between the domain owner > > > and the party managing the authoritative DNS. Even if this were > > > domain hijacking, a certificate issued that relied upon a proper > > > domain validation method is still proper issuance, technically. > > > Once this comes to light, there may be grounds for the proper > > > owner to get the certificate revoked, but the initial issuance was > > > proper as long as the validation was properly performed. > > > > > > > > >> > > >> > > >>> I'm not suggesting that the CA did anything untoward in issuing > > >>> this certificate. I am not suggesting that at all. > > >> > > >> My opinion is that if the CA was aware that the owner didn't > > >> ask/consent to that issuance, If it's not a misissuance according > > >> to the BRs, it should be. > > > > > > > > > Others can weigh in, but I'm fairly certain that it is not > > > misissuance according to the BRs. Furthermore, with respect to > > > issuance via domain validation, there's an intentional focus on > > > demonstrated control rather than ownership, as ownership is a > > > concept which can't really be securely validated in an automated > > > fashion. As such, I suspect it's unlikely that the industry or > > > browsers would accept such a > > change. > > > > > > > > > > I see this as a clear case of the profound confusion caused by the > community > > sometimes conflating "formal rule violation" with "misissuance". > > > > It would be much more useful to keep these concepts separate but > > overlapping: > > > > - A BR/MozPolicy/CPS/CP violation is when a certificate didn't > > follow > the > > official rules in some way and must therefore be revoked as a matter > > of compliance. > > > > - An actual misissuance is when a certificate was issued for a > > private > key held > > by a party other than the party identified in the certificate (in > Subject Name, > > SAN etc.), or to a party specifically not authorized to hold such a > certificate > > regardless of the identity (typically applies to SubCA, CRL-signing, > OCSP- > > signing, timestamping or other certificate types where relying party > trust > > doesn't check the actual name in the certificate). > > > > From these concepts, revocation requirements could then be > > reasonably classified according to the combinations (in addition to > > any specifics > of a > > situation): > > > > - Rule violation plus actual misissuance. This is bad, the 24 > > hours > or faster > > revocation rule should definitely be invoked. > > > > - Rule compliant misissuance. This will inevitably happen some > > times, > for > > example if an attacker successfully spoofs all the things checked by > > a > CA or > > exploits a loophole in the compliant procedures. This is the reason > > why > there > > must be an efficient revocation process for these cases. > > > > - Rule violation, but otherwise correct issuance. This covers any > kind of > > formal violation where the ground truth of the certified matter can > still be > > proven. Ranging from formatting errors (like having "-" in a field > > that > should > > just be omitted, putting the real name with spaces in the common > > name as originally envisioned in X.509, encoding CA:False > > etc.) over potentially dangerous errors (like having a 24 byte > > serial > number, > > which prevents some clients from checking revocation should it ever > become > > necessary) to directly dangerous errors (like having an unverified > DNS-syntax > > name in CN, or not including enough randomness in the serial number > > of an > > SHA-1 certificate). > > > > - Situation-changed no-longer valid issuance. This is when (as > recently > > discussed in a concrete case) a completely valid certificate > > contains information which is no longer true due to later events, > > such as a domain being sold without transfer of certificate private > > keys or a certified > entity (in > > OV/EV certs) ceasing to exist (company dissolved, person dead and > > estate disbursed). > > > > - Situation unchanged, but subject requests revocation. Also common. > > > > > > Enjoy > > > > Jakob > > -- > > Jakob Bohm, CIO, Partner, WiseMo A/S. > > https://clicktime.symantec.com/a/1/IoXGhI-fe8kwNzM3g- > > ij3FzWAbGFvMrNtD2R3BT4VXU=?d=7wLlWeFFMkVrq2bKotxDJwtyC74b57sB5 > > 4x-MgkeSS_T0hgGR_NUsGfosSO-6VXNZNEApN- > > 6cYoMqLiiYe3lGXMEJ9gzcEkJ3PsMPCg6umwu97ns0vPxoryh1m7GdjwdgbZcu > > eX0M5fiPjh0_- > > mO7Jnjt9ruhcNezF3pVz1DhkQCzcj0FYnQbKDfLAh43Gxt3OdSVb9TxbtDLbgKGJ > > W3WyeGcVY4tMSClly4-6y7fwBjenlra16rb- > > kI3L4t8J4BMAmK9JfLrXZ78LsAueqLB-Xg- > > wzZUyThkRRctCgaJ1UoLwTRAlRJAwKyNYr51VSAr19zzejj40TKydAk6b2Uhc2yV > > FvWZh77j2KE6QVqL788xrFfgAXuw2iMEOYVnXY1UiJtQj9lOOPmmcS9lQYg2uN > > 5TPcKEyvqxY09C1C6-jhHC8NOucgr1V9Q- > > 0whF7Ai1KwOSw%3D%3D&u=https%3A%2F%2Fwww.wisemo.com > > <http://2Fwww.wisemo.com> > > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > > This > public > > discussion message is non-binding and may contain errors. > > WiseMo - Remote Service Management for PCs, Phones and Embedded > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > <mailto:dev-security-policy@lists.mozilla.org> > > https://clicktime.symantec.com/a/1/ZvCXcGC_eekz0mymNP4JR8nwQjSjXnJW > > 3IqfLUaizek=?d=7wLlWeFFMkVrq2bKotxDJwtyC74b57sB54x- > > MgkeSS_T0hgGR_NUsGfosSO-6VXNZNEApN- > > 6cYoMqLiiYe3lGXMEJ9gzcEkJ3PsMPCg6umwu97ns0vPxoryh1m7GdjwdgbZcu > > eX0M5fiPjh0_- > > mO7Jnjt9ruhcNezF3pVz1DhkQCzcj0FYnQbKDfLAh43Gxt3OdSVb9TxbtDLbgKGJ > > W3WyeGcVY4tMSClly4-6y7fwBjenlra16rb- > > kI3L4t8J4BMAmK9JfLrXZ78LsAueqLB-Xg- > > wzZUyThkRRctCgaJ1UoLwTRAlRJAwKyNYr51VSAr19zzejj40TKydAk6b2Uhc2yV > > FvWZh77j2KE6QVqL788xrFfgAXuw2iMEOYVnXY1UiJtQj9lOOPmmcS9lQYg2uN > > 5TPcKEyvqxY09C1C6-jhHC8NOucgr1V9Q- > > 0whF7Ai1KwOSw%3D%3D&u=https%3A%2F%2Flists.mozilla.org > > <http://2Flists.mozilla.org> %2Flistinfo% > > 2Fdev-security-policy > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > <mailto: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 <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
