Re: Policy 2.7 Proposal: Clarify Meaning of "Technically Constrained"
Unless additional feedback is posted, I will include this change as originally proposed in version 2.7 of our policy. - Wayne On Fri, Mar 29, 2019 at 11:23 AM Wayne Thayer wrote: > On Fri, Mar 29, 2019 at 4:32 AM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 28/03/2019 21:52, Wayne Thayer wrote: >> > Our current Root Store policy assigns two different meanings to the term >> > "technically constrained": >> > * in sections 1.1 and 3.1, it means 'limited by EKU' >> > * in section 5.3 it means 'limited by EKU and name constraints' >> > >> > The BRs already define a "Technically Constrained Subordinate CA >> > Certificate" as: >> > >> > A Subordinate CA certificate which uses a combination of Extended Key >> Usage >> >> settings and Name Constraint settings to limit the scope within which >> the >> >> Subordinate CA Certificate may issue Subscriber or additional >> Subordinate >> >> CA Certificates. >> >> >> > >> > I propose aligning Mozilla policy with this definition by leaving >> > "technically constrained" in section 5.3, and changing "technically >> > constrained" in sections 1.1 and 3.1 to "technically capable of issuing" >> > (language we already use in section 3.1.2). Here are the proposed >> changes: >> > >> > >> https://github.com/mozilla/pkipolicy/commit/91fe7abdc5548b4d9a56f429e04975560163ce3c >> > >> > This is https://github.com/mozilla/pkipolicy/issues/159 >> > >> > I will appreciate everyone's comments on this proposal. In particular, >> > please consider if the change from "Such technical constraints could >> > consist of either:" to "Intermediate certificates that are not >> considered >> > to be technically capable will contain either:" will cause confusion. >> > >> >> To further reduce confusion, perhaps change the terminology in Mozilla >> policy to "Technically Constrained to Subscriber", meaning technically >> constrained to only be capable of issuing for a fully validated >> subscriber identity (validated as if some hypothetical kind of wildcard >> EE cert). >> >> > I think that "Technically Constrained to Subscriber" is more confusing and > not necessarily accurate in the case where the Subscriber is in control of, > but not the same as one of more of the permitted domain names, IP > addresses, or email addresses. > > This of cause remains applicable to all the kinds of identities >> recognized and regulated by the Mozilla root program, which currently >> happens to be server domain, EV organization, and e-mail address >> identities. >> >> I realize that the BR meaning may be intended to be so too, but many >> discussions over the years have indicated confusion. >> >> > Can you provide an example of the confusion that this additional change > would help to clarify? > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Policy 2.7 Proposal: Clarify Point-in-Time Audit Language
I will will include this change in policy version 2.7. - Wayne On Wed, Mar 27, 2019 at 8:04 PM Ryan Sleevi wrote: > I'm not sure whether it's necessary to indicate support, but since silence > can sometimes be ambiguously interpreted: I support these changes and > believe they achieve the desired outcome. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updated Revocation Best Practices
Ryan - Again, thank you for the feedback, and please forgive me for the
delayed response. I've attempted to address your concerns on the wiki page
(since this isn't official policy, I'm editing the live document):
https://wiki.mozilla.org/index.php?title=CA%2FResponding_To_An_Incident=revision=1210671=1207675
- Wayne
On Mon, Mar 18, 2019 at 12:00 PM Ryan Sleevi wrote:
>
>
> On Sat, Mar 16, 2019 at 12:49 PM Wayne Thayer wrote:
>
>> Ryan - Thank you for the feedback.
>>
>> On Fri, Mar 15, 2019 at 6:14 PM Ryan Sleevi wrote:
>>
>>> While I realize the thinking is with regards to the recent serial number
>>> issue, a few questions emerge:
>>>
>>> 1) Based on the software vendor reporting, they don’t view this as a
>>> software defect, but a CA misconfiguration. Do you believe the current
>>> policy, as worded, addresses that ambiguity?
>>>
>>>
>> As the language is an example, I don't believe it needs to address this
>> distinction. I intended "defect" to mean a defect in the certificate, so
>> perhaps it would help to specify that - i.e. "certificate defect"?
>>
>
> I guess the challenge is it introduces the ontology that some folks have
> advocated, but no one actually knows where the lines should be drawn, as
> every example has had flaws. That is, a "certificate defect" could be
> everything from granting basicConstraints:CA=true (e.g. as we saw with
> Turktrust [1]) due to a misconfigured certificate profile (which, like
> this, was an "off by one" error) to something like misencoded sequences [2].
>
> My biggest worry with the proposal is that it seems to actually favor not
> revoking/responding to systemic issues (those which can affect a
> significant portion of the CA's issued certificates), whereas I think the
> intent is that non-revocation should be exceptional and that the CA should
> be moving to systemically address things.
>
> I think the end-goal, for both cases, remains the same: that the CA take
> holistic steps to make revocation easier and painless, whether they're
> dealing with systemic issues (such as serial numbers or validation methods)
> or exceptional situations (such as a rogue RA or validation agent). Looking
> at Heartbleed as the example, we know that a massive number of Subscribers
> and certificates were affected - it seems like this example would have
> encouraged non-revocation, by choosing the size of impact as the
> illustrative example.
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=825022
> [2]
> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
>
>
>> 4) This new policy seems to explicitly allow a CA never revoking a
>>> non-compliant Certificate. Is that your intent? If so, is there any concern
>>> that this introduces the risk of CAs presenting revocation as being
>>> “required by Mozilla” as opposed to the factually correct and accurate
>>> “required by the Baseline Requirements” if Mozilla or this community should
>>> disagree with such a decision?
>>>
>>>
>> Is there any difference between delaying revocation until a certificate
>> expires and not revoking at all? Is there any difference between CAs
>> misrepresenting revocation as "being required by Mozilla to happen by X
>> date" and "being required by Mozilla"?
>>
>
> Fair points. I think the previous policy encouraged a more concrete plan
> of action ("when"), and did not leave the CA decision making capability
> ("if") which could create a conflict between the CA's decisions and the
> community expectations. That said, you make a good point - if their "when"
> is "when the certificate expires", then it's implicitly an "if" as well,
> and that remains unless/until "when" is more prescreptive.
>
>
>> 5) If multiple CAs are affected by a common incident, this seems to
>>> encourage delaying revocation as long as possible. It’s unclear whether a
>>> CA that can and does revoke their certificates will be more or less
>>> favorably considered, both by the ecosystem and by this community. Given
>>> the economic incentives, it seems to strongly discourage revocation, as a
>>> way of competitive differentiation.
>>>
>>>
>> I'm not following how these changes have the effect of encouraging
>> multiple CAs to delay revocation as long as possible. but I do think it
>> would be useful to state that CAs who violate the BRs will always be looked
>> upon less favorably than those who do not.
>>
>
> If a given CA is faced with a systemic issue - such as serial numbers -
> then they have a decision whether to replace a majority of certificates or
> not. Independent of any analysis, there will naturally be a preference to
> not revoke "if we don't have to". Because the encouragement to post on the
> Forum, and because these discussions show that people's opinions about the
> seriousness/reasonableness of the matter is, in some way, impacted by how
> many other CAs are impacted, there's a natural incentive to delay
> revocation as much as possible (and to draw out discussions as much
RE: Arabtec Holding public key? [Weird Digicert issued cert]
A possibility. They could have pasted something in the root chain. Note that the required handshake would have caught that if it'd been implemented. Overall it doesn't matter too much if was malicious or innocent, the cert holder can't do anything without the private key. -Original Message- From: dev-security-policy On Behalf Of Jakob Bohm via dev-security-policy Sent: Monday, April 15, 2019 4:58 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] Thanks for the explanation. Is it possible that a significant percentage of less-skilled users simply pasted in the wrong certificates by mistake, then wondered why their new certificates newer worked? Pasting in the wrong certificate from an installed certificate chain or semi-related support page doesn't seem an unlikely user error with that design. On 12/04/2019 18:56, Jeremy Rowley wrote: > I don't mind filling in details. > > We have a system that permits creation of certificates without a CSR that > works by extracting the key from an existing cert, validating the domain/org > information, and creating a new certificate based on the contents of the old > certificate. The system was supposed to do a handshake with a server hosting > the existing certificate as a form of checking control over the private key, > but that was never implemented, slated for a phase 2 that never came. We've > since disabled that system, although we didn't file any incident report (for > the reasons discussed so far). > > -Original Message- > From: dev-security-policy > On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Friday, April 12, 2019 10:39 AM > To: Jakob Bohm > Cc: mozilla-dev-security-policy > > Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] > > It's not clear that there is anything for DigiCert to respond to. Are we > asserting that the existence of this Arabtec certificate is proof that > DigiCert violated section 3.2.1 of their CPS? > > - Wayne > > On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 11/04/2019 04:47, Santhan Raj wrote: >>> On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: > (Resending after I typo'd the ML address) > > At the risk of further embarrassing myself in the same week, while > working further on mimicking Firefox trust decisions I found this > pre-certificate for Arabtec Holding PJSC: > > https://crt.sh/?id=926433948 > > Now there's nothing especially strange about this certificate, > except that its RSA public key is shared with several other > certificates > > >> https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2 >> d >> ab76254f97fb36b82fc26 > > ... such as the DigiCert Global Root G2: > > https://crt.sh/?caid=5885 > > > I would like to understand what happened here. Maybe I have once > again made a terrible mistake, but if not surely this means either > that the Issuing authority was fooled into issuing for a key the > subscriber doesn't actually have or worse, this Arabtec Holding > outfit has the private keys for DigiCert's Global Root G2 > > Nick. AFAIK there's no requirement in the BRs or Mozilla Root Policy for CAs >> to actually verify that the Applicant actually is in possession of >> the corresponding private key for public keys included in CSRs (i.e., >> check the signature on the CSR), so the most likely explanation is >> that the CA in question did not check the signature on the >> Applicant-submitted CSR and summarily embedded the supplied public >> key in the certificate (assuming Digicert's CA infrastructure wasn't >> compromised, but I think that's highly unlikely). A very similar situation was brought up on the list before, but with >> WoSign as the issuing CA: >> https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KB >> W >> 8/OlK44lmGCAAJ >>> >>> While not a BR requirement, the CA's CPS does stipulate validating >> possession of private key in section 3.2.1 (looking at the change >> history, it appears this stipulation existed during the cert >> issuance). So something else must have happened here. >>> >>> Except for the Arabtec cert, the other certs looks like cross-sign >>> for >> the Digicert root. >>> >> >> Why still no response from Digicert? Has this been reported to them >> directly? >> 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
Blog: Common CA Database (CCADB) promotes Transparency and Collaboration
All, I posted the following to the Mozilla Security Blog to explain what the CCADB is and why it is important. https://blog.mozilla.org/security/2019/04/15/common-ca-database-ccadb/ Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key? [Weird Digicert issued cert]
According to Jeremy (see below), that was not the situation. On 15/04/2019 14:09, Man Ho wrote: I don't think that it's trivial for less-skilled user to obtain the CSR of "DigiCert Global Root G2" certificate and posting it in the request of another certificate, right? On 15-Apr-19 6:57 PM, Jakob Bohm via dev-security-policy wrote: Thanks for the explanation. Is it possible that a significant percentage of less-skilled users simply pasted in the wrong certificates by mistake, then wondered why their new certificates newer worked? Pasting in the wrong certificate from an installed certificate chain or semi-related support page doesn't seem an unlikely user error with that design. On 12/04/2019 18:56, Jeremy Rowley wrote: I don't mind filling in details. We have a system that permits creation of certificates without a CSR that works by extracting the key from an existing cert, validating the domain/org information, and creating a new certificate based on the contents of the old certificate. The system was supposed to do a handshake with a server hosting the existing certificate as a form of checking control over the private key, but that was never implemented, slated for a phase 2 that never came. We've since disabled that system, although we didn't file any incident report (for the reasons discussed so far). 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: Arabtec Holding public key? [Weird Digicert issued cert]
I don't think that it's trivial for less-skilled user to obtain the CSR of "DigiCert Global Root G2" certificate and posting it in the request of another certificate, right? On 15-Apr-19 6:57 PM, Jakob Bohm via dev-security-policy wrote: > Thanks for the explanation. > > Is it possible that a significant percentage of less-skilled users > simply pasted in the wrong certificates by mistake, then wondered why > their new certificates newer worked? > > Pasting in the wrong certificate from an installed certificate chain or > semi-related support page doesn't seem an unlikely user error with that > design. > > On 12/04/2019 18:56, Jeremy Rowley wrote: >> I don't mind filling in details. >> >> We have a system that permits creation of certificates without a CSR >> that works by extracting the key from an existing cert, validating >> the domain/org information, and creating a new certificate based on >> the contents of the old certificate. The system was supposed to do a >> handshake with a server hosting the existing certificate as a form of >> checking control over the private key, but that was never >> implemented, slated for a phase 2 that never came. We've since >> disabled that system, although we didn't file any incident report >> (for the reasons discussed so far). >> >> -Original Message- >> From: dev-security-policy >> On Behalf Of Wayne >> Thayer via dev-security-policy >> Sent: Friday, April 12, 2019 10:39 AM >> To: Jakob Bohm >> Cc: mozilla-dev-security-policy >> >> Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] >> >> It's not clear that there is anything for DigiCert to respond to. Are >> we asserting that the existence of this Arabtec certificate is proof >> that DigiCert violated section 3.2.1 of their CPS? >> >> - Wayne >> >> On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> On 11/04/2019 04:47, Santhan Raj wrote: On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: > On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: >> (Resending after I typo'd the ML address) >> >> At the risk of further embarrassing myself in the same week, while >> working further on mimicking Firefox trust decisions I found this >> pre-certificate for Arabtec Holding PJSC: >> >> https://crt.sh/?id=926433948 >> >> Now there's nothing especially strange about this certificate, >> except that its RSA public key is shared with several other >> certificates >> >> >>> https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2d >>> ab76254f97fb36b82fc26 >> >> ... such as the DigiCert Global Root G2: >> >> https://crt.sh/?caid=5885 >> >> >> I would like to understand what happened here. Maybe I have once >> again made a terrible mistake, but if not surely this means either >> that the Issuing authority was fooled into issuing for a key the >> subscriber doesn't actually have or worse, this Arabtec Holding >> outfit has the private keys for DigiCert's Global Root G2 >> >> Nick. > > AFAIK there's no requirement in the BRs or Mozilla Root Policy for > CAs >>> to actually verify that the Applicant actually is in possession of the >>> corresponding private key for public keys included in CSRs (i.e., >>> check the signature on the CSR), so the most likely explanation is >>> that the CA in question did not check the signature on the >>> Applicant-submitted CSR and summarily embedded the supplied public key >>> in the certificate (assuming Digicert's CA infrastructure wasn't >>> compromised, but I think that's highly unlikely). > > A very similar situation was brought up on the list before, but > with >>> WoSign as the issuing CA: >>> https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KBW >>> 8/OlK44lmGCAAJ > While not a BR requirement, the CA's CPS does stipulate validating >>> possession of private key in section 3.2.1 (looking at the change >>> history, it appears this stipulation existed during the cert >>> issuance). So something else must have happened here. Except for the Arabtec cert, the other certs looks like cross-sign for >>> the Digicert root. >>> >>> Why still no response from Digicert? Has this been reported to them >>> directly? >>> > > > Enjoy > > Jakob ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Arabtec Holding public key? [Weird Digicert issued cert]
Thanks for the explanation. Is it possible that a significant percentage of less-skilled users simply pasted in the wrong certificates by mistake, then wondered why their new certificates newer worked? Pasting in the wrong certificate from an installed certificate chain or semi-related support page doesn't seem an unlikely user error with that design. On 12/04/2019 18:56, Jeremy Rowley wrote: I don't mind filling in details. We have a system that permits creation of certificates without a CSR that works by extracting the key from an existing cert, validating the domain/org information, and creating a new certificate based on the contents of the old certificate. The system was supposed to do a handshake with a server hosting the existing certificate as a form of checking control over the private key, but that was never implemented, slated for a phase 2 that never came. We've since disabled that system, although we didn't file any incident report (for the reasons discussed so far). -Original Message- From: dev-security-policy On Behalf Of Wayne Thayer via dev-security-policy Sent: Friday, April 12, 2019 10:39 AM To: Jakob Bohm Cc: mozilla-dev-security-policy Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert] It's not clear that there is anything for DigiCert to respond to. Are we asserting that the existence of this Arabtec certificate is proof that DigiCert violated section 3.2.1 of their CPS? - Wayne On Thu, Apr 11, 2019 at 6:57 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On 11/04/2019 04:47, Santhan Raj wrote: On Wednesday, April 10, 2019 at 5:53:45 PM UTC-7, Corey Bonnell wrote: On Wednesday, April 10, 2019 at 7:41:33 PM UTC-4, Nick Lamb wrote: (Resending after I typo'd the ML address) At the risk of further embarrassing myself in the same week, while working further on mimicking Firefox trust decisions I found this pre-certificate for Arabtec Holding PJSC: https://crt.sh/?id=926433948 Now there's nothing especially strange about this certificate, except that its RSA public key is shared with several other certificates https://crt.sh/?spkisha256=8bb593a93be1d0e8a822bb887c547890c3e706aad2d ab76254f97fb36b82fc26 ... such as the DigiCert Global Root G2: https://crt.sh/?caid=5885 I would like to understand what happened here. Maybe I have once again made a terrible mistake, but if not surely this means either that the Issuing authority was fooled into issuing for a key the subscriber doesn't actually have or worse, this Arabtec Holding outfit has the private keys for DigiCert's Global Root G2 Nick. AFAIK there's no requirement in the BRs or Mozilla Root Policy for CAs to actually verify that the Applicant actually is in possession of the corresponding private key for public keys included in CSRs (i.e., check the signature on the CSR), so the most likely explanation is that the CA in question did not check the signature on the Applicant-submitted CSR and summarily embedded the supplied public key in the certificate (assuming Digicert's CA infrastructure wasn't compromised, but I think that's highly unlikely). A very similar situation was brought up on the list before, but with WoSign as the issuing CA: https://groups.google.com/d/msg/mozilla.dev.security.policy/zECd9J3KBW 8/OlK44lmGCAAJ While not a BR requirement, the CA's CPS does stipulate validating possession of private key in section 3.2.1 (looking at the change history, it appears this stipulation existed during the cert issuance). So something else must have happened here. Except for the Arabtec cert, the other certs looks like cross-sign for the Digicert root. Why still no response from Digicert? Has this been reported to them directly? 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
