RE: Arabtec Holding public key? [Weird Digicert issued cert]

[Jeremy Rowley via dev-security-policy]

Unfortunately yes.  We plan on updating our CPS and bringing it up with our 
auditors during this audit, who is on-site next week.

 

From: Wayne Thayer  
Sent: Friday, April 12, 2019 11:30 AM
To: Jeremy Rowley 
Cc: Jakob Bohm ; mozilla-dev-security-policy 

Subject: Re: Arabtec Holding public key? [Weird Digicert issued cert]

 

Jeremy: do you consider the fact that DigiCert signed certs without proof of 
private key possession to have been a violation if its CPS?

 

On Fri, Apr 12, 2019 at 10:04 AM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

The net result were some people created private certs with our root cert public 
key. We signed new certs using that public key after verifying domain control. 
We saw the process happen a few times but didn't worry about it too much as the 
requesters didn't control the private key. We ended up shutting off the no-CSR 
path because we figured the issuance of these certs created a potential PR 
concern, even if there isn't a real security risk.

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Jeremy 
Rowley via dev-security-policy
Sent: Friday, April 12, 2019 10:56 AM
To: Wayne Thayer mailto:wtha...@mozilla.com> >; Jakob 
Bohm mailto:jb-mozi...@wisemo.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: RE: Arabtec Holding public key? [Weird Digicert issued cert]

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 mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Wayne 
Thayer via dev-security-policy
Sent: Friday, April 12, 2019 10:39 AM
To: Jakob Bohm mailto:jb-mozi...@wisemo.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
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 

Re: Arabtec Holding public key? [Weird Digicert issued cert]

[Wayne Thayer via dev-security-policy]

Jeremy: do you consider the fact that DigiCert signed certs without proof
of private key possession to have been a violation if its CPS?

On Fri, Apr 12, 2019 at 10:04 AM Jeremy Rowley 
wrote:

> The net result were some people created private certs with our root cert
> public key. We signed new certs using that public key after verifying
> domain control. We saw the process happen a few times but didn't worry
> about it too much as the requesters didn't control the private key. We
> ended up shutting off the no-CSR path because we figured the issuance of
> these certs created a potential PR concern, even if there isn't a real
> security risk.
>
> -Original Message-
> From: dev-security-policy 
> On Behalf Of Jeremy Rowley via dev-security-policy
> Sent: Friday, April 12, 2019 10:56 AM
> To: Wayne Thayer ; Jakob Bohm 
> Cc: mozilla-dev-security-policy <
> mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: RE: Arabtec Holding public key? [Weird Digicert issued cert]
>
> 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 <
> mozilla-dev-security-pol...@lists.mozilla.org>
> 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 

RE: Arabtec Holding public key? [Weird Digicert issued cert]

[Jeremy Rowley via dev-security-policy]

The net result were some people created private certs with our root cert public 
key. We signed new certs using that public key after verifying domain control. 
We saw the process happen a few times but didn't worry about it too much as the 
requesters didn't control the private key. We ended up shutting off the no-CSR 
path because we figured the issuance of these certs created a potential PR 
concern, even if there isn't a real security risk.

-Original Message-
From: dev-security-policy  On 
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Friday, April 12, 2019 10:56 AM
To: Wayne Thayer ; Jakob Bohm 
Cc: mozilla-dev-security-policy 
Subject: RE: Arabtec Holding public key? [Weird Digicert issued cert]

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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

RE: Arabtec Holding public key? [Weird Digicert issued cert]

[Jeremy Rowley via dev-security-policy]

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


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Arabtec Holding public key? [Weird Digicert issued cert]

[Wayne Thayer via dev-security-policy]

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=8bb593a93be1d0e8a822bb887c547890c3e706aad2dab76254f97fb36b82fc26
> >>>
> >>> ... 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/zECd9J3KBW8/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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Entropy of certificate serial number

[xipki via dev-security-policy]

Thanks for the detailed declaration. I did not consider that the serialNumber 
is in the very first block of hash input.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy