Possible violation of CAA by nazwa.pl

[michel.le...@gmail.com]

Hello,

My domain registrar who is also a certificate authority just issued a
precertificate (visible in CT logs) and a valid
certificate for my domain. This is part of their new offer to automatically offer free certificates for all of their domains:
https://www.nazwa.pl/certyfikaty-ssl/

I had a CAA record that only allowed letsencrypt.org to issue
certificates for my domain:
`lebihan.pl. 3600 IN CAA 0 issue
"letsencrypt.org"`


I think my domain registrar just violated my CAA by issuing that
certificate. Where they allowed to issue this certificate?

I also read that is is not recommended for certificate authorities to
generate private keys and certificates for clients. Shouldn't they only
sign certificate requests?

The precertificate is visible on Facebook Surveillance Certificate
Transparency:
https://developers.facebook.com/tools/ct/search/?query=lebihan.pl

The issuer is `C=PL, O=nazwa.pl sp. z o.o., OU=http:, nazwa.pl,
CN=nazwaSSL`.

[Quirin Scheitle]

Hi Michel,

> On 23. Jul 2018, at 22:36, michel.lebihan2000--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> I think my domain registrar just violated my CAA by issuing that
> certificate. Where they allowed to issue this certificate?

the name servers for lebihan.pl are ns[1-3].nazwa.pl. , which indicates that your hoster (nazwa.pl) also operates your name servers.

The certificate is issued by nazwaSSL, which links to Certum’s roots.

Checking against current version 1.6.0 of BRs, Sec 3.2.2.8 reads:

"CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS.”

So, if am not mistaken at some step, this is probably OK per current CAB BRs.

Kind regards
Quirin

[Matthew Hardeman]

Yes, I thought there was an exemption for that also.

The A-DNS operator could always just momentarily change the records to
authorize anyway, so why bother with the check?

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

[Wojciech Trapczyński]

W dniu 25.07.2018 o 23:21, Quirin Scheitle via dev-security-policy pisze:

> Hi Michel,
>
>> On 23. Jul 2018, at 22:36, michel.lebihan2000--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> I think my domain registrar just violated my CAA by issuing that
>> certificate. Where they allowed to issue this certificate?
>
> the name servers for lebihan.pl are ns[1-3].nazwa.pl. , which indicates that your hoster (nazwa.pl) also operates your name servers.
>
> The certificate is issued by nazwaSSL, which links to Certum’s roots.
>
> Checking against current version 1.6.0 of BRs, Sec 3.2.2.8 reads:
>
> "CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS.”
>
> So, if am not mistaken at some step, this is probably OK per current CAB BRs.

Hi,

Thank you.

I checked logs. In the moment of performing CAA verification for
lebihan.pl domain we found "certum.pl":

lebihan.pl. 300 IN CAA 0 issue "certum.pl"

"certum.pl" is specified in our CPS as an accepted CAA record.

I would like to highlight that we always check CAA record. Even if "the

CA or an Affiliate of the CA is the DNS Operator (as defined in
RFC 7719) of the domain's DNS"

--
Wojciech Trapczyński

[Tom]

On Wednesday, 25 July 2018 21:08:59 UTC, michel.le...@gmail.com wrote:
> Hello,
>
> My domain registrar who is also a certificate authority just issued a
> precertificate (visible in CT logs) and a valid
> certificate for my domain. This is part of their new offer to automatically offer free certificates for all of their domains:
> https://www.nazwa.pl/certyfikaty-ssl/
>
> I had a CAA record that only allowed letsencrypt.org to issue
> certificates for my domain:
> `lebihan.pl. 3600 IN CAA 0 issue
> "letsencrypt.org"`
>
>
> I think my domain registrar just violated my CAA by issuing that
> certificate. Where they allowed to issue this certificate?

Can you clarify if _you_ initiated the certificate request; or if the certificate was created and signed without any action from you?

I think those are two very difference cases. If you initiated it, they didn't CAA (because they weren't required to.) If you didn't... isn't that a rogue issuance?

-tom

[Matthew Hardeman]

I think the whole point of domain validation certificates is taking the
human part out of it and verifying technical control of the domain as the
standard upon which to base issuance.

Since the CA is also the DNS server, it's more or less a given that they
certainly can or would successfully validate. It's noteworthy that domain
validation is about demonstrating control rather than ownership. The party
actually running the authoritative DNS servers is in control of the domain.

I'm not suggesting that the CA did anything untoward in issuing this
certificate. I am not suggesting that at all.

I am, however, suggesting that even if they admitted to just creating a new
certificate for the domain without contacting the owner, I think that
wouldn't technically be a misissuance, right?

On Thu, Jul 26, 2018 at 10:40 AM, Tom via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, 25 July 2018 21:08:59 UTC, michel.le...@gmail.com wrote:

> > Hello,
> >
> > My domain registrar who is also a certificate authority just issued a
> > precertificate (visible in CT logs) and a valid
> > certificate for my domain. This is part of their new offer to
> automatically offer free certificates for all of their domains:
> > https://www.nazwa.pl/certyfikaty-ssl/
> >
> > I had a CAA record that only allowed letsencrypt.org to issue
> > certificates for my domain:
> > `lebihan.pl. 3600 IN CAA 0 issue
> > "letsencrypt.org"`
> >
> >
> > I think my domain registrar just violated my CAA by issuing that
> > certificate. Where they allowed to issue this certificate?
>
>

> Can you clarify if _you_ initiated the certificate request; or if the
> certificate was created and signed without any action from you?
>
> I think those are two very difference cases. If you initiated it, they
> didn't CAA (because they weren't required to.) If you didn't... isn't that
> a rogue issuance?
>
> -tom

[Tom Delmas]

> 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.

> 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.

[Matthew Hardeman]

On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy <
dev-secur...@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.

[Jakob Bohm]

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://www.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

[Tom Ritter]

Thanks Jakob, I think you summed things up well.

-tom

On 27 July 2018 at 01:46, Jakob Bohm via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:
> On 26/07/2018 23:04, Matthew Hardeman wrote:
>>

[Tim Hollebeek]

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=digice...@lists.mozilla.org> On Behalf Of Jakob
> Bohm via dev-security-policy
> Sent: Friday, July 27, 2018 2:46 AM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Possible violation of CAA by nazwa.pl
>
> On 26/07/2018 23:04, Matthew Hardeman wrote:

> 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

> 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-secur...@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%2Flistinfo%
> 2Fdev-security-policy

[Ryan Sleevi]

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.

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@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%2Flistinfo%
> > 2Fdev-security-policy

[Jeremy Rowley]

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.

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.

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@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%2Flistinfo%
> > 2Fdev-security-policy

[Ryan Sleevi]

On Sat, Jul 28, 2018 at 2:17 PM Jeremy Rowley <jeremy...@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.

> On Sat, Jul 28, 2018 at 4:39 AM Tim Hollebeek via dev-security-policy <
> dev-secur...@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=digice...@lists.mozilla.org> On Behalf Of
> > > bounces+Jakob
> > > Bohm via dev-security-policy
> > > Sent: Friday, July 27, 2018 2:46 AM
> > > To: mozilla-dev-s...@lists.mozilla.org
> > > Subject: Re: Possible violation of CAA by nazwa.pl
> > >
> > > On 26/07/2018 23:04, Matthew Hardeman wrote:

> > > _______________________________________________
> > > dev-security-policy mailing list
> > > dev-secur...@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%2Flistinfo%
> > > 2Fdev-security-policy

[Jakob Bohm]

As there has been some misunderstandings, let me clarify that the above
was posted to point out the following:

- Compliance with every policy in the world does not mean a certificate
was not misissued in a way that requires fast revocation. Arguing that
because policies were followed there was no misissuance is confused.
This was the mistake made in the post I responded to.

- The complete absence of misissuance and policy violations does not
imply that there are no reasons to revoke a certificate, perhaps
quickly.

- Not every formal policy violation should be considered egregious.
Over the years the polices regulating CAs have grown in number and
volume and tend to cover everything from rules to avoid very dangerous
practices to minutia of browser/client/protocol compatibility. It
makes perfect sense for the community to distinguish these, either
formally or on a case by case basis rather than blindly applying a
legalistic zero tolerance approach. I am specifically not suggesting
that CAs should be allowed to decide this on their own or proposing
how specific rules and cases should be classified, merely pointing out
that there are such differences.

[Jeremy Rowley]

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 <ry...@sleevi.com>
Sent: Saturday, July 28, 2018 8:25 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: Jakob Bohm <jb-mo...@wisemo.com>; Tim Hollebeek <tim.ho...@digicert.com>; mozilla-dev-s...@lists.mozilla.org; ry...@sleevi.com
Subject: Re: Possible violation of CAA by nazwa.pl







On Sat, Jul 28, 2018 at 2:17 PM Jeremy Rowley <jeremy...@digicert.com <mailto:jeremy...@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=digice...@lists.mozilla.org <mailto:digice...@lists.mozilla.org> > On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Friday, July 27, 2018 8:01 PM
To: Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> >
Cc: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> ; Jakob Bohm <jb-mo...@wisemo.com <mailto:jb-mo...@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-secur...@lists.mozilla.org <mailto:dev-secur...@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=digice...@lists.mozilla.org <mailto:digice...@lists.mozilla.org> > On Behalf Of
> > bounces+Jakob
> > Bohm via dev-security-policy
> > Sent: Friday, July 27, 2018 2:46 AM

> > To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
> > Subject: Re: Possible violation of CAA by nazwa.pl <http://nazwa.pl>
> >
> > On 26/07/2018 23:04, Matthew Hardeman wrote:

> > 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-secur...@lists.mozilla.org <mailto:dev-secur...@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-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Wayne Thayer]

This discussion has covered a lot of ground. Here are my comments:

1. Nazwa is not independently audited, nor are they a member of the Mozilla
root program. I am also unable to locate any information that makes Nazwa
an Affiliate of Certum. I believe they are simply a Certum reseller. In
this instance CAA processing is required. Certum states that the CAA record
was validated, leaving me to conclude that Nazwa changed the CAA record
without the domain name registrant's permission.

2. Nazwa is generating the key pair. We recently discussed Trustico [1] and
concluded that - for resellers - this practice is discouraged but not
forbidden. I would encourage Certum to review the Trustico incident and
consider the implications of Nazwa's practices.

3. While I agree that "misissued" as currently used is a very broad term, I
think this is okay. It has meaning in context, and there's no handy word to
replace "misissued" when referring to certificates "issued in violation of
a policy".

4. I agree with Ryan that attempting to categorize misissuance is harmful
to the community. As proposed, it makes non-compliance for policy issues -
in fact, for anything the CA wants to argue isn't a security risk -
tolerable. This is a very slippery slope that ends with MUST == SHOULD.

5. I'm still working on a CAB Forum ballot that relaxes revocation
requirements to 5 days in many cases [2]. Now that governance reform is
mostly complete, I plan to move forward with this.

6. For the most part, I view the revocation of misissued certificates as a
CA's decision to either follow or willingly violate the BRs. It may be
tolerated when a CA chooses not to revoke (or delay revocation), but that
still reduces my confidence in the CA. The only case in which I think
Mozilla should consider relieving a CA of their obligation to revoke under
the BRs is when doing so would have a substantial negative impact on
Mozilla's users.

7. While it would be nice have a bright line for distrust decisions, I
don't know how to achieve that given the number of factors involved. The
manner in which a CA responds to an incident, past history, and the
specific nature of the incident are among the subjective elements that
affect those decisions.

- Wayne

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/Xio6mrdxp2M/m38TJkblAgAJ
[2] https://github.com/cabforum/documents/compare/master...wthayer:patch-1

On Tue, Jul 31, 2018 at 8:38 AM Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
>