Re: Possible violation of CAA by nazwa.pl
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-security-policy@lists.mozilla.org> wrote: > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Possible violation of CAA by nazwa.pl
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 Sent: Saturday, July 28, 2018 8:25 PM To: Jeremy Rowley Cc: Jakob Bohm ; Tim Hollebeek ; 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 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 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 mailto:tim.holleb...@digicert.com> > Cc: mozilla-dev-security-pol...@lists.mozilla.org <mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Jakob Bohm 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
Re: Possible violation of CAA by nazwa.pl
On 27/07/2018 08:46, Jakob Bohm wrote: 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> 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. 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
Re: Possible violation of CAA by nazwa.pl
On Sat, Jul 28, 2018 at 2:17 PM Jeremy Rowley 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 digicert@lists.mozilla.org> On Behalf Of Ryan Sleevi via > dev-security-policy > Sent: Friday, July 27, 2018 8:01 PM > To: Tim Hollebeek > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm < > jb-mozi...@wisemo.com> > Subject: Re: Possible violation of CAA by 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> 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 > > bounces+tim.hollebeek=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 > > > Subject: Re: Possible violation of CAA by nazwa.pl > > >
RE: Possible violation of CAA by nazwa.pl
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. -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Friday, July 27, 2018 8:01 PM To: Tim Hollebeek Cc: mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm Subject: Re: Possible violation of CAA by 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> 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 > bounces+tim.hollebeek=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 > > Subject: Re: Possible violation of CAA by 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> 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 &
Re: Possible violation of CAA by 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> 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 > bounces+tim.hollebeek=digicert@lists.mozilla.org> On Behalf Of Jakob > > Bohm via dev-security-policy > > Sent: Friday, July 27, 2018 2:46 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: Possible violation of CAA by 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> 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, > > S
RE: Possible violation of CAA by nazwa.pl
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 bounces+tim.hollebeek=digicert@lists.mozilla.org> On Behalf Of Jakob > Bohm via dev-security-policy > Sent: Friday, July 27, 2018 2:46 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Possible violation of CAA by 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> 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 omitt
Re: Possible violation of CAA by nazwa.pl
Thanks Jakob, I think you summed things up well. -tom On 27 July 2018 at 01:46, Jakob Bohm via dev-security-policy wrote: > 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> 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://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 > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org
Re: Possible violation of CAA by 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> 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://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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible violation of CAA by nazwa.pl
On Thu, Jul 26, 2018 at 2:23 PM, Tom Delmas via dev-security-policy < 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. > > ___ > 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
Re: Possible violation of CAA by nazwa.pl
> 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible violation of CAA by nazwa.pl
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-security-policy@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.3600IN 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 > ___ > 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
Re: Possible violation of CAA by nazwa.pl
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.3600IN 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible violation of CAA by nazwa.pl
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 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 smime.p7s Description: Kryptograficzna sygnatura S/MIME ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Possible violation of CAA by nazwa.pl
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? On Wed, Jul 25, 2018 at 4:21 PM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Michel, > > > On 23. Jul 2018, at 22:36, michel.lebihan2000--- via dev-security-policy > 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 > ___ > 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
Re: Possible violation of CAA by nazwa.pl
Hi Michel, > On 23. Jul 2018, at 22:36, michel.lebihan2000--- via dev-security-policy > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Possible violation of CAA by nazwa.pl
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.3600IN 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`. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
