Re: OISTE WISeKey Global Root GC CA Root Inclusion Request
Hello, we successfully completed the new audits. As requested, we modified the audit period to ensure that there aren't gaps since the creation date of the new Root. The Webtrust seals are available here: Webtrust for CA: https://www.cpacanada.ca/webtrustseal?sealid=10026 Webtrust SSL BR: https://www.cpacanada.ca/webtrustseal?sealid=10027 Thanks and regards, Pedro El martes, 26 de junio de 2018, 23:11:08 (UTC+2), Wayne Thayer escribió: > On Tue, Jun 26, 2018 at 1:53 PM Pedro Fuentes via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > El martes, 26 de junio de 2018, 22:36:23 (UTC+2), Ryan Sleevi escribió: > > > > Hopefully the audit report will be just as boringly positive as usual... :) > > > > I'll come back then in a few weeks, once the audit process is over and we > > get the result. > > > > Thank you Pedro. My understanding, then, is that we will be placing this > inclusion request on hold until we receive the audit report covering the > period beginning on 9-May 2017. ___ 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
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
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 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. T
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, > > 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 happe
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 > > > 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 > > sometim
