RE: DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

Yeah - still trying to get that info. I'll update this list right when I
know what's been done.  I'm not 100% sure at this point, but I wanted to
post early and update than wait until I know everything.  Sorry - should
have specified that in the original email.

-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be] 
Sent: Tuesday, November 7, 2017 11:38 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert ROCA fingerprint incident report

Hi,

What I miss is what has been done to prevent new ones from being issued.


Kurt

On Tue, Nov 07, 2017 at 06:20:53PM +, Jeremy Rowley via
dev-security-policy wrote:
> Hey everyone,
> 
>  
> 
> Here's the DigiCert incident report about the ROCA fingerprints. Note 
> that these were all issued by Symantec (ie, before the transaction
closed).
> 
>  
> 
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We 
> became aware that DigiCert needed to take action on close (Nov 1).  At 
> that time, the new combined team launched an investigation to 
> determine the impacted certs. Six certs were identified and revoked:
> 
>  
> 
> 
> 4a907fbfc90eb043c50c9c8ace6305a1
> 
> 
> 8008c178d0d4cd3d79acc09f6ac132c
> 
> 
> 2dab9a2d40a2f55c5d705551cf7cafe5
> 
> 
> 306b67f5c25ee0fd495d2be88979eb72
> 
> 
> 7c7b826b183093ba1e5b9850ac31d806
> 
> 
> 4c834767e44ecbd0cdef8e60c04dcf32
> 
>  
> 
> These certs were all revoked around Nov 3, within 24 hours of 
> identifying the impacted certs at DigiCert.
> 
>  
> 
> Jeremy
> 



> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/ac3GKpOQNNTUgvdrINCg5TSocQpoIoCYQJm
> i6wdzR6s=?d=x6aCRo4VfXwciHJ72iOM_J1K3cmxLlV0aGOHiskoYAX0y17Wq9rBdSq-bg
> 4GrKAujQl5VZlxkGBYh01ZXYr8EygG-dNtE90f1YxT_GtuW58TCPLm7Mzjb03dlIVjjY5-
> Rjwup4G6ykol-8HJAhLROxtb1Gda2q-q68_5E0-B8lD0Vce3ByqdfnbDVs8EMtgtnbEqDO
> 6mDPSrslcUjJVelIOpVaxXMdNiBwpMKzmrMdj_V1r1S7QZYgVhUMqQIdLCSpsF3J_80G4P
> 0pGEj80fNBSwYUExVrYXgahNhnXwZBZ2uStpa7rDf1Za_6AmZUyOBJKYnpBkOQOvL_7APz
> 7ZWMYjlryr5kvZwlfwT2ceDE2ZfuZyVEaDmygE8KnF=https%3A%2F%2Flists.mozil
> la.org%2Flistinfo%2Fdev-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: DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

More info (that was sent to me a while ago, I just missed the report):

There we actually seven. I missed this one:
Serial: "a18e9"

We installed a patch to stop accepting ROCA keys for TLS certs on
2017-10-26.  A patch for code signing and email certs is coming shortly.
Once that patch is installed, we will repeat our scans for any additional
vulnerable certificates that were issued in the interim.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, November 7, 2017 11:40 AM
To: Kurt Roeckx <k...@roeckx.be>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: DigiCert ROCA fingerprint incident report

Yeah - still trying to get that info. I'll update this list right when I
know what's been done.  I'm not 100% sure at this point, but I wanted to
post early and update than wait until I know everything.  Sorry - should
have specified that in the original email.

-Original Message-
From: Kurt Roeckx [mailto:k...@roeckx.be]
Sent: Tuesday, November 7, 2017 11:38 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert ROCA fingerprint incident report

Hi,

What I miss is what has been done to prevent new ones from being issued.


Kurt

On Tue, Nov 07, 2017 at 06:20:53PM +0000, Jeremy Rowley via
dev-security-policy wrote:
> Hey everyone,
> 
>  
> 
> Here's the DigiCert incident report about the ROCA fingerprints. Note 
> that these were all issued by Symantec (ie, before the transaction
closed).
> 
>  
> 
> We became aware of the issue when it was posted to the mailing list.
> However, at that time, the certs were not operated by DigiCert. We 
> became aware that DigiCert needed to take action on close (Nov 1).  At 
> that time, the new combined team launched an investigation to 
> determine the impacted certs. Six certs were identified and revoked:
> 
>  
> 
> 
> 4a907fbfc90eb043c50c9c8ace6305a1
> 
> 
> 8008c178d0d4cd3d79acc09f6ac132c
> 
> 
> 2dab9a2d40a2f55c5d705551cf7cafe5
> 
> 
> 306b67f5c25ee0fd495d2be88979eb72
> 
> 
> 7c7b826b183093ba1e5b9850ac31d806
> 
> 
> 4c834767e44ecbd0cdef8e60c04dcf32
> 
>  
> 
> These certs were all revoked around Nov 3, within 24 hours of 
> identifying the impacted certs at DigiCert.
> 
>  
> 
> Jeremy
> 



> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/ac3GKpOQNNTUgvdrINCg5TSocQpoIoCYQJm
> i6wdzR6s=?d=x6aCRo4VfXwciHJ72iOM_J1K3cmxLlV0aGOHiskoYAX0y17Wq9rBdSq-bg
> 4GrKAujQl5VZlxkGBYh01ZXYr8EygG-dNtE90f1YxT_GtuW58TCPLm7Mzjb03dlIVjjY5-
> Rjwup4G6ykol-8HJAhLROxtb1Gda2q-q68_5E0-B8lD0Vce3ByqdfnbDVs8EMtgtnbEqDO
> 6mDPSrslcUjJVelIOpVaxXMdNiBwpMKzmrMdj_V1r1S7QZYgVhUMqQIdLCSpsF3J_80G4P
> 0pGEj80fNBSwYUExVrYXgahNhnXwZBZ2uStpa7rDf1Za_6AmZUyOBJKYnpBkOQOvL_7APz
> 7ZWMYjlryr5kvZwlfwT2ceDE2ZfuZyVEaDmygE8KnF=https%3A%2F%2Flists.mozil
> la.org%2Flistinfo%2Fdev-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: DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

I believe so – I asked that they all be logged, but I’ll need to double check 
whether it got done. 

 

From: Alex Gaynor [mailto:agay...@mozilla.com] 
Sent: Tuesday, November 7, 2017 11:23 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert ROCA fingerprint incident report

 

Hi Jeremy,

 

Have all these certificates been submitted to CT?

 

Thanks!

Alex

 

On Tue, Nov 7, 2017 at 1:20 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hey everyone,



Here's the DigiCert incident report about the ROCA fingerprints. Note that
these were all issued by Symantec (ie, before the transaction closed).



We became aware of the issue when it was posted to the mailing list.
However, at that time, the certs were not operated by DigiCert. We became
aware that DigiCert needed to take action on close (Nov 1).  At that time,
the new combined team launched an investigation to determine the impacted
certs. Six certs were identified and revoked:




4a907fbfc90eb043c50c9c8ace6305a1


8008c178d0d4cd3d79acc09f6ac132c


2dab9a2d40a2f55c5d705551cf7cafe5


306b67f5c25ee0fd495d2be88979eb72


7c7b826b183093ba1e5b9850ac31d806


4c834767e44ecbd0cdef8e60c04dcf32



These certs were all revoked around Nov 3, within 24 hours of identifying
the impacted certs at DigiCert.



Jeremy


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

DigiCert ROCA fingerprint incident report

[Jeremy Rowley via dev-security-policy]

Hey everyone, 

 

Here's the DigiCert incident report about the ROCA fingerprints. Note that
these were all issued by Symantec (ie, before the transaction closed).

 

We became aware of the issue when it was posted to the mailing list.
However, at that time, the certs were not operated by DigiCert. We became
aware that DigiCert needed to take action on close (Nov 1).  At that time,
the new combined team launched an investigation to determine the impacted
certs. Six certs were identified and revoked:

 


4a907fbfc90eb043c50c9c8ace6305a1


8008c178d0d4cd3d79acc09f6ac132c


2dab9a2d40a2f55c5d705551cf7cafe5


306b67f5c25ee0fd495d2be88979eb72


7c7b826b183093ba1e5b9850ac31d806


4c834767e44ecbd0cdef8e60c04dcf32

 

These certs were all revoked around Nov 3, within 24 hours of identifying
the impacted certs at DigiCert. 

 

Jeremy



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: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Hi everyone, 

 

We met the December 1 deadline of integrating with Symantec systems, and all 
validation and issuance of TLS certificates is currently flowing through 
DigiCert’s  backend. Initial results appear generally positive, with the 
validation staff processing orders and delivering certificates. Symantec 
customers are using their existing Symantec front-end ordering systems. As 
expected with any migration of this scale, we are working directly with 
customers in the instances that require additional customer support.

 

Thought I’d let everyone here know we are live with the operations. I plan to 
post an update with more information about how things went after we have some 
run-rate data. Let me know if you have questions.

 

Jeremy



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: CA generated keys

[Jeremy Rowley via dev-security-policy]

I think key escrow services are pretty rare related to TLS certs. However,
there's lots of CAs and services that escrow signing keys for s/MIME certs.
Although, I'm not sure how companies can claim non-repudiation if they've
escrowed the signing key, a lot of enterprises use dual-use keys and want at
least the encryption portion in case an employee leaves.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Monday, December 11, 2017 12:48 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA generated keys

Hi Tim,

The more I think about it, the more I see this is actually a interesting
question :-)

I suspect the first thing Mozilla allowing this would do would be to make it
much more common. (Let's assume there are no other policy
barriers.) I suspect there are several simpler workflows for certificate
issuance and installation that this could enable, and CAs would be keen to
make their customers lives easier and reduce support costs.

On 09/12/17 18:20, Tim Hollebeek wrote:
> First, third parties who are *not* CAs can run key generation and 
> escrow services, and then the third party service can apply for a  
> certificate for the key, and deliver the certificate and the key to a
customer.

That is true. Do you know how common this is in SSL/TLS?

> I'm not
> sure how this could be prevented.  So if this actually did end up 
> being a Mozilla policy, the practical effect would be that SSL keys 
> can be generated by third parties and escrowed, *UNLESS* that party is
trusted by Mozilla.

Another way of putting it it: "unless that party were the party the customer
is already dealing with and trusts". IoW, there's a much lower barrier for
the customer in getting the CA to do it (trust and
convenience) compared to someone else. So removing this ban would probably
make it much more common, as noted above. If it's something we want to
discourage even if we can't prevent it, the current ban makes sense.

> Second, although I strongly believe that in general, as a best 
> practice, keys should be generated by the device/entity it belongs to 
> whenever possible, we've seen increasing evidence that key generation 
> is difficult and many devices cannot do it securely.  I doubt that 
> forcing the owner of the device to generate a key on a commodity PC is 
> any better (it's probably worse).

That's also a really interesting question. We've had dedicated device key
generation failures, but we've also had commodity PC key generation failures
(Debian weak keys, right?). Does that mean it's a wash? What do the risk
profiles look like here? One CA uses a MegaRNG2000 to generate hundreds of
thousands of certs.. and then a flaw is found in it. Oops.
Better or worse than a hundred thousand people independently using a broken
OpenSSL shipped by their Linux vendor?

> With an increasing number of small devices running web servers, keys 
> generated by audited, trusted third parties under whatever rules 
> Mozilla chooses to enforce about secure key delivery may actually in 
> many circumstances be superior than what would happen if the practice is
banned.

Is there a way to limit the use of this to those circumstances?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/7IiyfqIYVYHVo4yJwZ1gujE6ewgPbVhdeNR8nQYMk
tE=?d=-Wn_VctZunngdEk_ioG0-YmJpPH0bSY7avkVy2G5jkppW7WbRwmFtauXnqI4GVKzIanQD2
ZA6NInKdI3JGkcf9ryTq6n-s4c4pg5s3wE4vkp4yda03M7jQfN5_Ag8-70lEsjQb45m2On8sIoG_
dT07uGS0eLuIUFBs5Ejb7aU7SMDef-aiw2SMmHSy34HrobgXESUV5rtJhwEAyCZvSWTdlhTt2mUM
XVuNXdmFtAYun19fEnhCuxZTm44Inip_9XUfKb73PIvmELdwusC79xu_WgoRGUvPUEFfEYMZQJLz
r1wo3PfgH3YtIhu55H4aSMlU8UOVe5JjW6WYG0wIKfKfGKta_cm5JB9HGONmcRvB8nw-A2xd5kr6
jSh2Pb6kH9EJMOhxcnioBU4Gm_IH7he9MnhbhTu2BATkoSNvbqOoNB=https%3A%2F%2Flists
.mozilla.org%2Flistinfo%2Fdev-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: DRAFT November 2017 CA Communication

[Jeremy Rowley via dev-security-policy]

Some initial thoughts
1. I'm a bit confused by bullet #2 in the survey. Wasn't it already the
Mozilla policy that CAs could only use the blessed 10 methods of validation?
I thought this was communicated in the previous letter? 
2.  On bullet #3, I'm reading the wording to mean either 1) disclosed and
audited or 2) revoked, not  disclosed and either a) revoked or b) audited,
correct? Rewording the language to be "must be either audited and disclosed
or revoked in the Common CA Database" might clarify between the two. 
3. On bullet #3, should you specify what audits are required for s/MIME in
the email? There might be confusion between the two audit questions that
interprets s/MIME as requiring a BR audit. This might not be worth
clarifying though as all CAs should understand the purpose of each audit.
4. On action 4, how often will Mozilla require BR Self assessments? Should
you state that Mozilla may require them on a periodic basis going forward? 
5. On action 7, I'm unaware of any CT discussions currently ongoing at the
CAB Forum or Mozilla list.  Could you provide a link or further intent on
what we're watching for? 

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Kathleen Wilson via dev-security-policy
Sent: Wednesday, October 25, 2017 1:47 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: DRAFT November 2017 CA Communication

All,

I will greatly appreciate your thoughtful and constructive feedback on the
DRAFT of Mozilla's next CA Communication, which I am hoping to send in early
November.

https://wiki.mozilla.org/CA/Communications#November_2017_CA_Communication

Direct link to the survey:
https://ccadb-public.secure.force.com/mozillacommunications/CACommunicationS
urveySample?CACommunicationId=a051J3mogw7

Thanks,
Kathleen

___
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: Proposed policy change: require private pre-notification of 3rd party subCAs

[Jeremy Rowley via dev-security-policy]

Assuming the rule applies only to externally run third parties, I think it's
an excellent idea, but perhaps it should be a public pre-notification? As
you mentioned, the relationship will become transparent through CCDAB
submission and the audit report, so what's the advantage of keeping it
private?

One of the biggest issues with external Sub CAs is they don't go through the
root embedment process.  Having a public "review" period where the intent to
cross-sign is known gives the community transparency into the operation and
participation into the process. This process could help a CA from making a
bad cross-signing mistake. 

Jeremy

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Doug Beattie via dev-security-policy
Sent: Tuesday, October 24, 2017 9:44 AM
To: Gervase Markham ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Proposed policy change: require private pre-notification of 3rd
party subCAs

Gerv,

I assume this applies equally to cross signing, but not to "Vanity" CAs that
are set up and run by the CA on behalf of a customer.  Is that accurate?

Doug

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Tuesday, October 24, 2017 11:28 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Proposed policy change: require private pre-notification of 
> 3rd party subCAs
> 
> One of the ways in which the number of organizations trusted to issue 
> for the WebPKI is extended is by an existing CA bestowing the power of 
> issuance upon a third party in the form of control of a 
> non-technically-constrained subCA. Examples of such are the Google and 
> Apple subCAs under GeoTrust, but there are others.
> 
> Adding new organizations to the list of those trusted is a big deal, 
> and currently Mozilla has little pre-insight into and not much control 
> over this process. CAs may choose to do this for whoever they like, 
> the CA then bears primary responsibility for managing that customer, 
> and as long as they are able to file clean audits, things proceed as
normal.
> 
> Mozilla is considering a policy change whereby we require private pre- 
> notification of such delegations (or renewals of such delegations).
> We would not undertake to necessarily do anything with such 
> notifications, but lack of action should not be considered permissive in
an estoppel sense.
> We would reserve the right to object either pre- or post-issuance of 
> the intermediate. (Once the intermediate is issued, of course, the CA 
> has seven days to put it in CCADB, and then the relationship would 
> probably become known unless the fields in the cert were misleading.)
> 
> This may not be where we finally want to get to in terms of regulating 
> such delegations of trust, but it is a small step which brings a bit 
> more transparency while acknowledging the limited capacity of our team 
> for additional tasks.
> 
> Comments are welcome.
> 
> Gerv
> ___
> 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: Statement on DigiCert’s Proposed Purchase of Symantec

[Jeremy Rowley via dev-security-policy]

A couple of points of clarification (as it seems to have stirred some questions)
1. Migration to the DigiCert issuing and validation process only applies to 
certs intended for browser use, meaning the infrastructure may issue code 
signing, email, etc certs post Dec 1. These certs will be validated and issued 
from existing Symantec infrastructure using Symantec validation processes, at 
least until we finish migration to DigiCert.
2. When I refer to "infrastructure" I mean Symantec's validation and issuing 
systems related to TLS certificates.  We may reuse the front end systems and 
hardware used to provide these systems post day 1.  Note that we definitely 
plan to migrate customers to a consolidated experience, but I want to be clear 
and transparent about what is migrating when. Dec 1 is only the TLS backend.

Thanks!
Jeremy

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org]
 On Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, October 31, 2017 2:08 PM
To: Gervase Markham <g...@mozilla.org>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Statement on DigiCert’s Proposed Purchase of Symantec

Thanks Gerv and Kathleen. We really appreciate you posting this, and I find the 
Mozilla guidance extremely helpful.  Here's where we are at with the current 
migration plan:

1) As of Dec. 1, DigiCert will validate and issue all certificates requested 
through Symantec.  Symantec's front end systems, including their certificate 
management platform, tools, and services, will remain functional and operate as 
post-close. 
2) Post Dec 1, DigiCert plans to consolidate operations onto a single 
infrastructure, including platforms, tools, user experience, and operations.  
For Mozilla users, the consolidation means a one path for all validation and 
certificate issuance. Our new, v2, validation process simplifies the process 
previously offered by either company while implementing additional checks to 
detect and prevent mis-issuance. We expect the entire consolidation to take 
about a year. 
3) DigiCert has always considered validation a trusted role that requires 
extensive training and reviews. As of Dec 1, all former Symantec personnel 
involved in validation will receive training on DigiCert's operations, systems, 
and culture.  Issuance of certificates will only be permitted after completion 
of the training.
4) Continuously, we will look to take the best from both company’s processes, 
and our focus will be on relying on DigiCert’s processes, culture and values 
and supplementing that with Symantec’s scale to do great things for security.  
This will happen throughout the consolidation process to ensure we take 
experiences from both companies and create something amazing.
5) Now that we’ve closed, we can freely pursue the cross-signings discussed on 
Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1401384). I’m going to 
make an update on that bugzilla today that shows the final architecture and 
names of the issuing CAs. The key ceremony is planned for end of this week. 
Once complete, we’ll add them to CCDAB and distribute them to interested 
entities. 

To answer a couple of points directly:

* We would be concerned if the combined company continued to operate 
  significant pieces of Symantec’s old infrastructure as part of their 
  day-to-day issuance of publicly-trusted certificates. 
- All certificates will be issued and validated by DigiCert as of Dec 1. We do 
not plan to run any of Symantec’s old infrastructure. Post Dec 1, we are 
consolidating the other systems (API, interfaces, tools, etc) to further 
eliminate paths into the CA and reduce risk.  

* We would be concerned if Symantec validation and operations personnel 
  continued their roles without retraining in DigiCert methods and 
  culture. 
- DigiCert considers validation a trusted role, meaning we require extensive 
training and reviews. All Symantec validation and operations personnel will use 
DigiCert’s systems going forward and receive training from DigiCert management. 
 We plan on starting this training right away. In addition, we are 
consolidating the validation team to a couple of central locations. That 
combined with the DigiCert validation safeguards should ensure a more robust 
validation experience. We are also going to work hard on keeping the DigiCert 
culture alive.  We value transparency, employee and customer satisfaction, and 
security (not necessarily in that order) and want to continue with those 
virtues.  

* We would be concerned if Symantec processes appeared to displace 
  DigiCert processes. 
- What we really hope to do is learn from both DigiCert’s and Symantec’s 
process to create something new during the transition that is better than 
either one alone. The integration between the two companies is a perfect time 
to look at how both companies can improve and implement somet

CT Log deprecation

[Jeremy Rowley via dev-security-policy]

Hi everyone, 

 

I posted our announcement about deprecation of Symantec CT logs over on the
Google list a while ago. I figured I'd post something here as well so the
community is aware of our plans.

 

As part of our infrastructure consolidation DigiCert will be EOLing legacy
Symantec CT log servers listed below at the end of September 2018.

https://ct.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=483625 )

https://vega.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=554549#c18 )

https://sirius.ws.symantec.com/ct/v1
(https://bugs.chromium.org/p/chromium/issues/detail?id=692782#c24 )

 

Google seems to operate mirrors for these log servers as announced here
https://www.ietf.org/mail-archive/web/trans/current/msg01485.html 

 

>>> 

- Google is building out log mirrors for all logs included by Chrome,

  and the intent is that read-only requests from Chrome (for STHes, or

  inclusion-proofs (via the DNS mechanism above)) will be serviced by a

  log mirror, rather than the underlying logs.

>>> 

 

These links show the actual mirror for each of above CT Logs:

 
https://ct.grahamedgecombe.com/logs/10

 
https://ct.grahamedgecombe.com/logs/14

 
https://ct.grahamedgecombe.com/logs/31

 

Many CAs apart from DigiCert (legacy Symantec) currently use at least one of
these log servers to log their EV/OV certificates. We strongly recommend
that CAs that currently use any of these log servers should start using any
other log servers in the CT ecosystem as soon as possible (or set up their
log). This will give these CAs enough time to secure permissions (if
required) for using an alternate log server from its operator and complete
integration with it. Legacy Symantec log servers will fully cease to operate
after EOL.

 

If you have specific questions please use the  contact email published with
each log server or contact me.

 

Jeremy



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: Disallowed company name

[Jeremy Rowley via dev-security-policy]

Punctuation differences are not enough to register a name in the us, or at 
least in the jurisdictions here I’m aware of.  

> On Jun 4, 2018, at 1:04 AM, Ryan Hurst via dev-security-policy 
>  wrote:
> 
> I apologize, I originally wrote in haste and did not clearly state what I
> was suggesting.
> 
> Specifically, while it is typical for a given jurisdiction (state, etc) to
> require a name to be unique, it is typically not a requirement for it to
> not be so unique that it can not be confused for another name. For example,
> I have seen businesses registered with punctuation and without; I have also
> seen non-latin characters in use in business names this clearly has the
> potential to introduce name confusion.
> 
> Ryan
> 
> On Fri, Jun 1, 2018 at 11:55 PM, Matthew Hardeman 
> wrote:
> 
>> 
>> 
>> On Fri, Jun 1, 2018 at 10:28 AM, Ryan Hurst via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>> 
>>> 
>>> re: Most of the government offices responsible for approving entity
>>> creation are concerned first and foremost with ensuring that a unique name
>>> within their jurisdiction is chosen
>>> 
>>> What makes you say that, most jurisdictions have no such requirement.
>>> 
>>> 
>> This was anecdotal, based on my own experience with formation of various
>> limited liability entities in several US states.
>> 
>> Even my own state of Alabama, for example, (typically regarded as pretty
>> backwards) has strong policies and procedures in place for this.
>> 
>> In Alabama, formation of a limited liability entity whether a Corporation
>> or LLC, etc, begins with a filing in the relevant county probate court of
>> an Articles of Incorporation, Articles or Organization, trust formation
>> documents, or similar.  As part of the mandatory filing package for those
>> document types, a name reservation certificate (which will be validated by
>> the probate court) from the Alabama Secretary of State will be required.
>> The filer must obtain those directly from the appropriate office of the
>> Alabama Secretary of State.  (It can be done online, with a credit card.
>> The system enforces entity name uniqueness.)
>> 
> ___
> 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: Disallowed company name

[Jeremy Rowley via dev-security-policy]

*Some cas. I don’t think the 18 month requirement is a universal position and 
may not even be a majority view.  I think there’s other ideas that are better 
and add more value than simply extending the time a company is required to 
exist to get the cert.

> On May 31, 2018, at 4:40 PM, Wayne Thayer via dev-security-policy 
>  wrote:
> 
> On Thu, May 31, 2018 at 8:39 PM James Burton via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
>> 
>> This is wrong and should be changed to allow all types of legally
>> incorporated company names to get certificates. I understand this
>> doesn't fit any of the standard company name profiles you've seen but this
>> company name can be used in practice  and I can think of many business
>> types that would love this type of name.
>> 
>> In my opinion, this is just a rehash of the same debate we've been having
> over misleading information in certificates ever since James obtained the
> "Identity Verified" EV certificate. The options we have to address this
> seem to be:
> 1. Accept that some entities, based on somewhat arbitrary rules and
> decisions, can't get OV or EV certs
> 2. Accept that the organization information in certificates will sometimes
> be misleading or at least uninformative
> 3. Decide that organization information in certificates is irrelevant and
> ignore it, or get rid of it
> 
> We currently have chosen "some parts of all of the above" :-)
> 
> I am most interested in exploring the first option since that is the
> direction CAs are headed with the recent proposal to limit EV certificates
> to organizations that have existed for more than 18 months [1]. As long as
> anyone can obtain a DV certificate, are restrictions on who can obtain an
> OV or EV certificate a problem, and if so, why?
> 
> [1] https://cabforum.org/pipermail/validation/2018-May/000882.html
> ___
> 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: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

RFC 6844: "The Certification Authority Authorization (CAA) DNS Resource
Record
   allows a DNS domain name holder to specify the Certification
   Authorities (CAs) authorized to issue certificates for that domain. "

CAA record checks would be outside the scope of revocation requests. 

I'm not sure I agree with " In any event, proof of ability to modify the
authoritative DNS over each label in the certificate should almost certainly
suffice to revoke a previously issued certificate that relied exclusively
upon just about any other sort of domain validation."

But only because I doubt every CA supports DNS checking, and I know several
companies where the people operating the DNS are not the same  entities
authorized to manage certificates. 


-Original Message-
From: dev-security-policy

On Behalf Of Matthew Hardeman via dev-security-policy
Sent: Friday, June 1, 2018 5:17 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy
; Jakob Bohm
; Wayne Thayer 
Subject: Re: Namecheap refused to revoke certificate despite domain owner
changed

On Fri, Jun 1, 2018 at 2:38 PM, Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is one of the reasons I think we should require an OID specifying 
> the validation method be included in the cert. Then you can require 
> the CA support revocation using the same validation process as was 
> used to confirm certificate authorization. With each cert logged in 
> CT, everyone in the world will know exactly how to revoke an 
> unauthorized or no-longer-wanted cert.
>
>
I agree that it would be forensically interesting to have that data
available in the certificate.  I question whether a policy of using only the
same method of demonstrating control anew is appropriate as a policy for
granting revocation.

There is a hierarchy of supremacy in domain validation.  The party
controlling the NS delegations from the registry has absolute precedence
over the present effective DNS server administrator, should they choose to
flex it.  The party immediately in effective control of the authoritative
DNS takes precedence over a website admin within the domain.

Consider that now current CAA records and policy (for good cause, even)
might presently prohibit successful validation via the method previously
utilized to acquire the certificate that the current domain holder wishes to
have revoked.  (Even if only by specifying a new CA, rather than the CA that
previously issued the certificate for which revocation is being
sought.)  Would you then advocate that if the validation can succeed -- save
for the CAA mismatch -- that this be regarded as sufficient evidence to
revoke?  That probably deserves some careful thought.

In any event, proof of ability to modify the authoritative DNS over each
label in the certificate should almost certainly suffice to revoke a
previously issued certificate that relied exclusively upon just about any
other sort of domain validation.
___
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: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

I was thinking more that this would be the minimum where a CA is required to 
revoke. For example, if the revocation requester can demonstrate control in the 
same fashion as the certificate issued, then the CA MUST revoke. This likely 
wouldn’t be the only way a CA would be required to revoke. And I do agree it 
won’t solve all cases. However, if the CA was able to issue a certificate using 
a particular domain control mechanism, shouldn’t they also be able to complete 
the domain control mechanism for revocation? Perhaps the domain holder cannot 
but that shouldn’t necessarily prevent the CA from supporting it. 

 

 

From: Ryan Sleevi  
Sent: Friday, June 1, 2018 4:08 PM
To: Jeremy Rowley 
Cc: r...@sleevi.com; Wayne Thayer ; Jakob Bohm 
; mozilla-dev-security-policy 

Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

Yes, as mentioned in the CABF in the first link Wayne provided, even for our 
other methods, it can be problematic for domain holders to demonstrate control 
using particular methods. As Joanna mentioned, .2 can be problematic in a 
post-WHOIS world.

 

I realize that shooting down suggestions doesn't help us build sustainable 
solutions, but this was a problem we thought about a lot in the context of the 
CT redaction discussions, because the only 'effective' mitigation to 
inappropriate redaction was reveal-(and-revoke) - that is, reveal the redacted 
name, and possibly revoke the cert if you don't like what was revealed. Trying 
to decide how to authorize that request and what the consequences of that would 
be occupied a substantial part of our time (... I promise I didn't hate 
redaction "just because").

 

As an example scenario beyond what Wayne pointed out in the 
https://cabforum.org/pipermail/public/2018-January/012824.html link, consider 
such situations such as All CAs being required to support all validation 
methods for revocation. One possible scenario is a lack of interoperable 
interpretations of some methods (yet compliant with the letter) - for example, 
GlobalSign's validation methods compared to Let's Encrypt's use of the (draft) 
ACME validation methods, which comply with the letter but are different 
protocols. Another possible scenario is that a CA only supports a given method 
for revocation, not issuance, and thus the robustness of it and the testing of 
it is far weaker than might be expected (and detected) for domain validation. 

 

Understandably, we can try to patch those two examples I gave (and there is 
useful result in doing so), such as trying to further specify exactly how 
domains are validated, or potentially requiring CAs to also support all such 
methods for domain validation as well (although determining whether that means 
CAs MUST also support DV is a related and natural implication that follows that 
sort of policy). However, I was trying to present them to indicate the sort of 
holistic challenges we should think about, and why it's not quite as easy as 
'revoke the same way you validated' or 'validate using any/every possible 
method'.

 

So what does that mean for Richard? Well, I agree with Jakob in that he quoted 
the appropriate section, and there is a reasonable expectation in principle for 
the CA to do due diligence to investigate for possible revocation. And I think 
Wayne's directions on revocation do offer a number of important contributions 
to that, by providing some degree of flexibility for CAs to do meaningful 
investigations (although with some degree of transparency inevitably being 
needed when offering CA discretion). And I think the Root Stores have a role to 
play in how they communicate that expectation to CAs, such that domain holders 
have recourse if the CA is not taking meaningful steps.

 

On Fri, Jun 1, 2018 at 5:42 PM, Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

Which is yet another reason why removing method 1 and method 5 was a good idea. 
 Do any of the other methods share the same problem? Maybe IP address 
verification right now.

 

From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Friday, June 1, 2018 2:51 PM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: Wayne Thayer mailto:wtha...@mozilla.com> >; Jakob 
Bohm mailto:jb-mozi...@wisemo.com> >; 
mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >


Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

You know I'm strongly supportive of requiring disclosure of validation methods, 
for the many benefits it brings, I'm not sure how that would address the 
concern.

 

Consider a certificate validated under .5. Would Richard now need to hire a 
lawyer to say they own their domain name now?

 

On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This is one of the reasons I think we should require 

RE: Disallowed company name

[Jeremy Rowley via dev-security-policy]

Can you point to a jurisdiction that allows you to register the same name? I've 
never seen an example where it's permitted. Maybe the UK?

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Ryan Hurst via dev-security-policy
Sent: Friday, June 1, 2018 9:28 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Disallowed company name

On Thursday, May 31, 2018 at 3:07:36 PM UTC-7, Matthew Hardeman wrote:
> On Thu, May 31, 2018 at 4:18 PM, Peter Saint-Andre via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >
> >
> > We can also think of many business types (e.g., scammers) that would 
> > love to have names like ⒶⓅⓅⓁⒺ but that doesn't mean it's smart to 
> > issue certificates with such names. The authorities who approve of 
> > company names don't necessarily have certificate handling in mind...
> >
> 
> Indeed.  Most of the government offices responsible for approving 
> entity creation are concerned first and foremost with ensuring that a 
> unique name within their jurisdiction is chosen and that a public 
> record of the entity creation exists.  They are not concerned with 
> risk management or legitimacy, broadly speaking.
> 
> Anyone at any level of risk management in the rest of the ecosystem 
> around a business will be concerned with such matters.  Banks, trade 
> vendors, etc, tend to reject accounts with names like this.  Perhaps 
> CAs should look upon this similarly.

re: Most of the government offices responsible for approving entity creation 
are concerned first and foremost with ensuring that a unique name within their 
jurisdiction is chosen

What makes you say that, most jurisdictions have no such requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/H8qZVRE5_iLNO8giNWdHECRPUnhWmem4t7fNC9FYfaI=?d=3yPd_yGx1m4dQz3H1uWi0wkNACGDGvIL4Z--LNoP9eDPIWeD0dhf9Ol_tFkJGBJFFgtnLt2HO_UCbFnaqQu3zUWQTHxGduRJO0a_H4yYE3qhYRX3wzvleMJ_cCcflYSP6doSbnmNReFJlR_Gjut8oNV6EnnecC1kzxXkdJG19OPUi3qjxKSp_r4Tlk3ExNNIwR3DF26nn1z6wKDyzP1siUdOGQT4oa70wTAPNZrK417n5z35ynmL65-hmQXBJkPLvbJL_UkzAgimEa4Sjh8YgHtKR2tCSas65vpsh0YyIXTny7Puzb8Hvs9uNxGPMfSyStkq2pMn3jZpzjfKsgYMMKDzdouOUktqhPACnhr6Qsx3ZdCTubWI8EkLpQsj4nYxjihAKD9mM-9LyUQGRh4mQOOQ0U4zY3qAE6fPOz-Upa5efnAlQhO0GtTkcOHiosY%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

This is one of the reasons I think we should require an OID specifying the 
validation method be included in the cert. Then you can require the CA support 
revocation using the same validation process as was used to confirm certificate 
authorization. With each cert logged in CT, everyone in the world will know 
exactly how to revoke an unauthorized or no-longer-wanted cert.

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Friday, June 1, 2018 1:02 PM
To: Jakob Bohm 
Cc: mozilla-dev-security-policy 
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 
> requires the CA (not some reseller) to revoke the certificate within 24 hours 
> if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, 
> they must revoke once made aware of the situation (in this case by you 
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. 
> In
practice, I believe that the requirement Jakob quoted is rarely invoked because 
(despite the examples), the language is too vague and narrow. It can also be 
quite difficult for a CA to verify that the revocation request is coming from 
the legitimate domain name registrant [1], making it less likely the CA will 
take action.

I've made a couple of attempts to fix this, resulting in the current language 
proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or control 
for any Fully-Qualified Domain Name or IP address in the Certificate should not 
be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke by 
proving that they control the domain name using one of the BR 3.2.2.4 methods, 
but this is a problem because most CAs don't support every domain validation 
method and many domains are configured such that some validation methods can't 
be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
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: Namecheap refused to revoke certificate despite domain owner changed

[Jeremy Rowley via dev-security-policy]

Which is yet another reason why removing method 1 and method 5 was a good idea. 
 Do any of the other methods share the same problem? Maybe IP address 
verification right now.

 

From: Ryan Sleevi  
Sent: Friday, June 1, 2018 2:51 PM
To: Jeremy Rowley 
Cc: Wayne Thayer ; Jakob Bohm ; 
mozilla-dev-security-policy 
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

 

You know I'm strongly supportive of requiring disclosure of validation methods, 
for the many benefits it brings, I'm not sure how that would address the 
concern.

 

Consider a certificate validated under .5. Would Richard now need to hire a 
lawyer to say they own their domain name now?

 

On Fri, Jun 1, 2018 at 3:38 PM, Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This is one of the reasons I think we should require an OID specifying the 
validation method be included in the cert. Then you can require the CA support 
revocation using the same validation process as was used to confirm certificate 
authorization. With each cert logged in CT, everyone in the world will know 
exactly how to revoke an unauthorized or no-longer-wanted cert.


-Original Message-
From: dev-security-policy 
mailto:digicert@lists.mozilla.org> > On Behalf Of Wayne Thayer via 
dev-security-policy
Sent: Friday, June 1, 2018 1:02 PM
To: Jakob Bohm mailto:jb-mozi...@wisemo.com> >
Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Namecheap refused to revoke certificate despite domain owner 
changed

On Fri, Jun 1, 2018 at 5:06 PM Jakob Bohm via dev-security-policy < 
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

>
> Please contact the CA again, and inform them that BR 4.9.1.1 #6 
> requires the CA (not some reseller) to revoke the certificate within 24 hours 
> if:
>
> The CA is made aware of any circumstance indicating that use of a
> Fully-Qualified Domain Name or IP address in the Certificate is no
> longer legally permitted (e.g. a court or arbitrator has revoked a
> Domain Name Registrant’s right to use the Domain Name, a relevant
> licensing or services agreement between the Domain Name Registrant
> and the Applicant has terminated, or the Domain Name Registrant has
> failed to renew the Domain Name);
>
> While CAs are not required to discover such situations themselves, 
> they must revoke once made aware of the situation (in this case by you 
> telling them).
>
> At least, this is how I read the rules.
>
> This issue has come up in several CAB Forum discussions such as [1]. 
> In
practice, I believe that the requirement Jakob quoted is rarely invoked because 
(despite the examples), the language is too vague and narrow. It can also be 
quite difficult for a CA to verify that the revocation request is coming from 
the legitimate domain name registrant [1], making it less likely the CA will 
take action.

I've made a couple of attempts to fix this, resulting in the current language 
proposed for ballot 213 [2]:

The CA obtains evidence that the validation of domain authorization or control 
for any Fully-Qualified Domain Name or IP address in the Certificate should not 
be relied upon.

I'd prefer a more prescriptive requirement that CAs allow anyone to revoke by 
proving that they control the domain name using one of the BR 3.2.2.4 methods, 
but this is a problem because most CAs don't support every domain validation 
method and many domains are configured such that some validation methods can't 
be used.

- Wayne

[1] https://cabforum.org/pipermail/public/2018-January/012824.html
[2] https://cabforum.org/pipermail/public/2018-May/013380.html
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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 
<mailto: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: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

Without the private key, im not sure how we're supposed to confirm key 
compromise. 

> On Dec 25, 2017, at 3:32 AM, Adrian R. via dev-security-policy 
>  wrote:
> 
> The BattleNet app needs to be installed and running, i am logged in with a 
> battlenet account.
> 
> the public certificate is attached below and i don't know how to get the 
> private key from inside the app, but it must be there since it runs as local 
> webserver on 127.0.0.1
> 
> Adrian R.
> 
> -BEGIN CERTIFICATE-
> MIIFbTCCBFWgAwIBAgIQCn+uUpLudsH09lYYIPTK5DANBgkqhkiG9w0BAQsFADBw
> MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
> d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
> dXJhbmNlIFNlcnZlciBDQTAeFw0xNzEyMTMwMDAwMDBaFw0xODEyMTgxMjAwMDBa
> MHQxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMQ8wDQYDVQQHEwZJ
> cnZpbmUxJTAjBgNVBAoTHEJsaXp6YXJkIEVudGVydGFpbm1lbnQsIEluYy4xGDAW
> BgNVBAMTD2xvY2FsYmF0dGxlLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
> AQoCggEBAL7pCsdGFhOe0aTk/1zPuBhD+5dc4Lg6VMg+Y+HRfJv9nlLfFoDKS2dy
> 3cwPTW3NaQqNRhGug5ODBsoLUOI7heT4tiv91yQ+OlIFENsS1vWgba85ifIKt3pS
> PG6kLc96nZ3JLpU4qjXOiF14/BECtNfBnIRsq60Vd/STWSNo84XrEvYBraTXT7Pg
> kkU2DFeUcl9pvfcsLmtJ4tUk1E1euL7cqQxN5LRr+6hPyhN1rqB5SEaWoIaUd4OD
> stR4H8RbxCXunIUS3o1O12cWAt4q4jDTay+8Bqy0sYGPvlLSOHMSrWHshpMGMVUL
> Plh5pKpXQn78usEyTw4O3hDPFnHv4McCAwEAAaOCAf0wggH5MB8GA1UdIwQYMBaA
> FFFo/5CvAgd1PMzZZWRiohK4WXI7MB0GA1UdDgQWBBTlPRA/nSH/T/W5QfGmpEwp
> YI/YEzAvBgNVHREEKDAmgg9sb2NhbGJhdHRsZS5uZXSCE3d3dy5sb2NhbGJhdHRs
> ZS5uZXQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
> BQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5odHRwOi8vY3JsMy5kaWdpY2VydC5jb20v
> c2hhMi1oYS1zZXJ2ZXItZzYuY3JsMDSgMqAwhi5odHRwOi8vY3JsNC5kaWdpY2Vy
> dC5jb20vc2hhMi1oYS1zZXJ2ZXItZzYuY3JsMEwGA1UdIARFMEMwNwYJYIZIAYb9
> bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMw
> CAYGZ4EMAQICMIGDBggrBgEFBQcBAQR3MHUwJAYIKwYBBQUHMAh0dHA6Ly9v
> Y3NwLmRpZ2ljZXJ0LmNvbTBNBggrBgEFBQcwAoZBaHR0cDovL2NhY2VydHMuZGln
> aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkhpZ2hBc3N1cmFuY2VTZXJ2ZXJDQS5jcnQw
> DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAaAidMTizU/KDox3Rd/Ak
> 9u/iGbGjwssc9582FoRQVBdOxVkvxNWy/+9As/v6HUhZhWRBYOPMwvMSYBufNcdq
> +zrEK8uJU4T0zI684pqzVsPwpFw3t9JzcdTZGScrD5//7fAkTql4YW9FGTyWz4ka
> qXwt19R615xxFBGPt25jaB2vZHXrHl3v49GkntFpvlKLwhlidcrVg1F3px4di7c3
> OR82PbAnjipHzg0KXZWZdbRh3IliYgoH31ygkuVKLd3HrmsDIXYe+zN/nWLA6tw0
> O9NKI7THpe62be+Anarbvj9x3/78+rojqMl/oXpiNEKl/lOYuFKomtt+sA7NxNL0
> kg==
> -END CERTIFICATE-
> 
> 
> 
>> On Monday, 25 December 2017 12:17:36 UTC+2, Hanno Böck  wrote:
>> On Sun, 24 Dec 2017 23:07:56 -0800 (PST)
>> "Adrian R. via dev-security-policy"
>>  wrote:
>> 
>>> on any computer with BattleNet installed and active go to this url:
>>> 
>>> https://127.0.0.1:22886/
>>> and currently it uses this certificate... which doesn't appear on
>>> crt.sh yet
>> 
>> I'm not able to reproduce this. Right now if I install battle.net I
>> don't get a listening port on 22886 at all. Can you please export the
>> certificate and send it here?
>> 
>> 
>> -- 
>> Hanno Böck
>> https://clicktime.symantec.com/a/1/KJ0TLgnYKZG-ejHetbcPBoY5C8CMG9KRMt9YyMceby0=?d=fO2IqqaZwQxg4Bl6je7HihqX4BwX3heoNAZ6Ao3Bbh-ZpLB4qQgiU5CmyPuOD8NWCz9gv85sYbbcZ1l1t8R3UTKhyDW52L-jg9Vz2Hyl9vfOgHz_AA9HJQHNOcb2eZ4OhJR5fnPamqCiwKn8b1nV0pu3xM2zoa4Q0lb4ATr99pNs_wVygwgGJQ5eaO6zSL9wsXXNl9AatjLXtzFyGDgWy1yQd34gBaX4k_nzBA4nU0Pq4ZiA9h-VPA_zmRkR5eDje0sj16DMWt25rv6JF1kWlONq20bzzGc8lUw1WXoO26AHtVdjGzQYYW33-MOaaablM8Ka4yXt81k8DvnPhuS3CI36-dY5vwg5IbGzdLcur26YRYofF9jujrtV8NSkEPsUjS3VuwYXPwsZJk4NRq8350X8PFMC6Ij8P537O4KivC9qADjbjoJod8hYsDHq-yBH6OAoqtUk2sa-RFDa2jJL2iCOahUFGPrzI3nS7hUytgV8nLz-im2zgmlj8SugEWHP3uti6uJLAnqu5H4ncJhMQLvmYQ%3D%3D=https%3A%2F%2Fhboeck.de%2F
>> 
>> mail/jabber: ha...@hboeck.de
>> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://clicktime.symantec.com/a/1/5e71ho7sLxNPxkirDsU3_VlvVsHU9OQ7rJ9O5JzCRNo=?d=fO2IqqaZwQxg4Bl6je7HihqX4BwX3heoNAZ6Ao3Bbh-ZpLB4qQgiU5CmyPuOD8NWCz9gv85sYbbcZ1l1t8R3UTKhyDW52L-jg9Vz2Hyl9vfOgHz_AA9HJQHNOcb2eZ4OhJR5fnPamqCiwKn8b1nV0pu3xM2zoa4Q0lb4ATr99pNs_wVygwgGJQ5eaO6zSL9wsXXNl9AatjLXtzFyGDgWy1yQd34gBaX4k_nzBA4nU0Pq4ZiA9h-VPA_zmRkR5eDje0sj16DMWt25rv6JF1kWlONq20bzzGc8lUw1WXoO26AHtVdjGzQYYW33-MOaaablM8Ka4yXt81k8DvnPhuS3CI36-dY5vwg5IbGzdLcur26YRYofF9jujrtV8NSkEPsUjS3VuwYXPwsZJk4NRq8350X8PFMC6Ij8P537O4KivC9qADjbjoJod8hYsDHq-yBH6OAoqtUk2sa-RFDa2jJL2iCOahUFGPrzI3nS7hUytgV8nLz-im2zgmlj8SugEWHP3uti6uJLAnqu5H4ncJhMQLvmYQ%3D%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

I think this raises a question on what level of investigation and assumption is 
required by the ca. Let's encrypt, for example, requires submission of the 
private key for revocation (https://letsencrypt.org/docs/revoking/). Is simply 
providing a reference rather than the key sufficient?

On Dec 25, 2017, at 7:52 AM, Adrian R. via dev-security-policy 
>
 wrote:

1) get a virtual machine
2) install windows, install the Blizzard BattleNet client.
3) create a BattleNet account with any email address - it's free, 
subscription/payment is not required for this.
4) login in the BattleNet app client with the account from step 3.

5) after the main BattleNet interface appears and shows that the user is 
properly logged in to their BattleNet account, open
https://127.0.0.1:22886/
in a web browser on the same virtual machine

result: this screen appears: 
https://clicktime.symantec.com/a/1/H8EylvFRu5AobRkYFh6nEMe_PZIqmSax2Rvqek2FeJs=?d=1yfch_0HocrSV8WeVgZeGsaOOneJ-8cF9bP7yzmp3HXKFGdjeJepYJf6HznnulZj_1Hv1P6Nn-z52PWlor45BiQi65emSMiq-1FjmlLPbEJBtMBbrUogI-Fp6ObsZErl07MAEKeXnIGAYXu493v19485GnXENM8m8015gWJTQdTruz3ruoXnJWdgFJOmflAh0pAb96BgaUR0o3r4BfbPSjVEuaW3jwhMObKUSCA8KQhf20VbylP8ssdWsAlXVpURT5gn4xW12jWxlyLw8Wdo-O5i5iN42A0yKRO3nel-TAJKnwHG0jjPGK9JrCbzjOttwrRwEpdAsa0nBiwHtSqNpBTHtj4vUi-H1XO01dG2eqm6SJgI-ZhQBPSRUgjoHicpibap-jFCjemQVsIxzJMxH_mrPbvx2JXc3bPaMsi5Qyu97ZVLxNl9HqE9sy8JeWu-_M70XHnI_NyNgcaCS24Q2mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D=https%3A%2F%2Fimgur.com%2Fv5vqedX


On Monday, 25 December 2017 16:44:03 UTC+2, Jeremy Rowley  wrote:
Without the private key, im not sure how we're supposed to confirm key 
compromise.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/7yhaM2O2nJci9TxwV_RD8qfnr-mmoGnbt-5pz2kQ8pA=?d=1yfch_0HocrSV8WeVgZeGsaOOneJ-8cF9bP7yzmp3HXKFGdjeJepYJf6HznnulZj_1Hv1P6Nn-z52PWlor45BiQi65emSMiq-1FjmlLPbEJBtMBbrUogI-Fp6ObsZErl07MAEKeXnIGAYXu493v19485GnXENM8m8015gWJTQdTruz3ruoXnJWdgFJOmflAh0pAb96BgaUR0o3r4BfbPSjVEuaW3jwhMObKUSCA8KQhf20VbylP8ssdWsAlXVpURT5gn4xW12jWxlyLw8Wdo-O5i5iN42A0yKRO3nel-TAJKnwHG0jjPGK9JrCbzjOttwrRwEpdAsa0nBiwHtSqNpBTHtj4vUi-H1XO01dG2eqm6SJgI-ZhQBPSRUgjoHicpibap-jFCjemQVsIxzJMxH_mrPbvx2JXc3bPaMsi5Qyu97ZVLxNl9HqE9sy8JeWu-_M70XHnI_NyNgcaCS24Q2mU5G8b_nfn9Hilet-VRsCIqD2QrmBC8XvVEQJ1FYtdHiQVDvhxWG-dP8Or2sZg7A3vFdA%3D%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

BTW - this certificate was revoked.

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla
.org] On Behalf Of Mark Steward via dev-security-policy
Sent: Friday, December 29, 2017 11:30 AM
To: Matthew Hardeman 
Cc: mozilla-dev-security-policy

Subject: Re: Certificates with shared private keys by gaming software (EA
origin, Blizzard battle.net)

On Mon, Dec 25, 2017 at 7:50 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Part of the trouble in relying upon the name alone is that on many 
> OS's (maybe all -- at least all the ones that matter for client side 
> work) can have localhost overridden to mean other things.
>
>
The main issue I see is that it effectively breaks SOP. It's not reasonable
to expect a user to know what app is listening on what port whenever a
browser connects, or to ensure that only Battle.net could listen on 28866.


> ...



If I recall correctly, this is actually more of a thing for WebSockets.
>
> If my recollection is correct, Chrome already considers 
> http://localhost or is it http://127.0.0.1 to be a secure origin in 
> nature.  Thus, code which arises from a request to localhost is 
> treated as running within a secure context, even if it is not wrapped 
> in a TLS connection.  (You can run javascript and access APIs in such 
> circumstances on localhost via HTTP when ordinarily Chrome would 
> require HTTPS to enable that access.)
>
> However...  That doesn't help the web developer who is trying to 
> access a WebSocket service on localhost.  While Chrome regards the 
> localhost as a secure origin, WebSockets in Chrome (and every other 
> mainstream browser?) require the connection to be a TLS wrapped one, 
> regardless of whether or not it's from a secure origin.
>
> (I wonder if they even wrote a protocol handler for non-secure web 
> sockets?  At the moment, it's Christmas and I'm being too lazy to 
> look.)
>
>
If by non-secure websockets you mean ws://, then yes, and Chrome is lax here
in that it allows access to ws://localhost from https:// without logging a
Mixed Content warning (Firefox only allows ws://localhost from http://).

I think the real issue is (anticipated) fallout of the move to HTTPS by
default, possibly along with the deprecation of Flash. I don't think there's
a clean solution for creating a socket from a website to an app on the local
machine, except maybe via WebRTC?


Mark
___
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: Certificates with shared private keys by gaming software (EA origin, Blizzard battle.net)

[Jeremy Rowley via dev-security-policy]

I’m pretty sure EA revoked the cert.

> On Dec 25, 2017, at 9:23 AM, Hanno Böck <ha...@hboeck.de> wrote:
> 
> On Mon, 25 Dec 2017 14:43:21 +
> Jeremy Rowley via dev-security-policy
> <dev-security-policy@lists.mozilla.org> wrote:
> 
>> Without the private key, im not sure how we're supposed to confirm
>> key compromise. 
> 
> I've pinged a few people with the right skillset to try to extract the
> key. But if there are people here who feel capable feel free. (I already
> tried the "simple" means, e.g. grepping through files.)
> 
> But one question: In the case of EA the cert got revoked and nobody
> asked for the key as evidence. What happened there? Did EA ask for the
> revocation? (I made them aware, but I have no knowledge of what happened
> afterwards.)
> 
> -- 
> Hanno Böck
> https://clicktime.symantec.com/a/1/7E2647SolTSFOrmTr1pTA6SaNlzWBEeOvNPzQjcoj-Q=?d=umuIBG9-qCSr0Ylk6iYyIG3WeDTsVZikMcWOz_90PD3etIywoX7mdbgM5-o7RmsLsolZOKJ5Yd7icx5CeHssMAD1UiN3APXXUDDjiwPDtMurIvGC1HUEmDwsAqBNjurJb-MIs_jopfZdcgY8mxha-DU3cggVxUKUpNesVOFzY4crbfh1T7v41ePXIqcjijQ5aiIrkZW7KPQhtK0KI34OyF_MPpj2n6Qwe3uXjjiKkflcD6tc0TslmbWo45ySkZr4IN9bmDJwyvSkZBodxAx7nt14NKzoWv2Mva865UkPqyNQF_sU7EOLF98PY4vHaeQFD-z9YZXHQxZjsTCqILJKF6XLJBIUOlZRa_LrXPQ8DxHY7YqNM4c8olIBYR8DWed9-LY-7juzWP3pT-3XoQanCUnEbUsgq1BNL8yQ_OU%3D=https%3A%2F%2Fhboeck.de%2F
> 
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
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

[Jeremy Rowley via dev-security-policy]

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

RE: Possible violation of CAA by nazwa.pl

[Jeremy Rowley via dev-security-policy]

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 
 ; Jakob Bohm 
mailto: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 

Issuance with improper domain validation

[Jeremy Rowley via dev-security-policy]

I posted this to Bugzilla last night. Basically, we had an issue with
validation that resulted in some certs issuing without proper (post-Aug 1)
domain verification. Still working out how many. The major reason was lack
of training by the validation staff combined with a lack of strict document
controls in the early part of the Symantec-DigiCert transition. 

 

1. How your CA first became aware of the problem (e.g. via a problem report
submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
the time and date.

 

On 2018/08/07 at 17:00 UTC, a customer submitted a request for information
about our validation process for the verification of four of their domains.
Upon investigation, we found that the four domains were not properly
validated using a post-Aug 1 domain validation method.  When attempting to
revalidated the domains prior to August 1, the random value was sent to an
address other than the WHOIS contact. This launched a broader investigation
into our overall revalidation efforts. This investigation is ongoing.  

 

2. A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.

>From approximately February through April 2018, DigiCert permitted some
legacy Symantec customers to use Method 1 to validate their domains. Use of
the method was subject to manager approval and reserved only for those
companies that had urgent replacement deadlines that could not be met with
an alternative validation method. Under this process, prior to approval, the
validation staff was required to match the WHOIS company information and
obtain approval using the WHOIS email address. 

 

Around April, this process was modified to include a BR-compliant Random
Value that the validation staff sent using the WHOIS contact information.
Use of the random value indicated acceptance.  Adding the random value
effectively transformed the validation from Method 1 to Method 2. The email
could include multiple domains with the understanding that the WHOIS contact
information had to match each domain listed. 

 

We believe that in some cases either the validation staff failed to match
the WHOIS contact information for each domain listed, approving the
certificate solely based on the existing verified registrant info, or the
system did not check whether the WHOIS contact information matched the email
address used in the original confirmation. 

 

On Aug 1, 2018, Ballot 218 took effect, deprecating Method 1.

 

On, August 7, 2018, a customer requested the audit trail of a certificate
issued using our new process. Upon review, validation management discovered
the validation was improper because the previously verified email contact
information did not match the WHOIS contact information.  This discovery
created an escalation up to management.

 

On August 13, 2018, we stopped all issuance based on the process that
converted Method 1 validations to Method 2 validations. 

 

We're currently investigating and will post an update when we know the
number of certificates and more about what went wrong. For now, we know the
number of impacted certificates is just under 2,500. We should have a
clearer picture shortly, after we have conducted a manual review of all
2,500 certificates.

 

3. Whether your CA has stopped, or has not yet stopped, issuing certificates
with the problem. A statement that you have will be considered a pledge to
the community; a statement that you have not requires an explanation.

 

On August 13, although most of these validations were likely properly
completed, we stopped issuance using information converted from Method 1
until completing a more thorough investigation.

 

4. A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem were issued.

 

Approximately 2,500 certificates are under review for validation issues. We
wanted to get the incident report out quickly as an FYI while our
investigation continues. We'll update this section in a final report.

 

5. The complete certificate data for the problematic certificates. The
recommended way to provide this is to ensure each certificate is logged to
CT and then list the fingerprints or crt.sh IDs, either in the report or as
an attached spreadsheet, with one list per distinct problem.

 

Still under review. We will upload them to the bug once we have a complete
list. Because the error was human, we are reviewing each validation to
determine whether Method 2 was correctly used.  Once we complete our review,
we'll post a Bugzilla attachment with the links for revoked certificates.

 

6. Explanation about how and why the mistakes were made or bugs 

RE: New certificate from compromised key

[Jeremy Rowley via dev-security-policy]

Thanks. We've revoked the cert and are looking into what happened and will post 
more information as we figure out what happened.  


-Original Message-
From: dev-security-policy  On 
Behalf Of Hanno Böck via dev-security-policy
Sent: Friday, August 17, 2018 7:16 PM
To: dev-security-policy@lists.mozilla.org
Subject: New certificate from compromised key

Hi,

Some of you may remember the discussion about embedded private keys in 
Blizzard's battle.net software here:
https://clicktime.symantec.com/a/1/XSDo7RID7Ms9aljAAOVAKoWLKhovvM_IrWUufr3rx9Y=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fgroups.google.com%2Fforum%2F%23%21msg%2Fmozilla.dev.security.policy%2Fpk039T_wPrI%2FVYi629oGCwAJ

One of the certificates with a compromised key back then was issued by
Digicert:
https://clicktime.symantec.com/a/1/8QluDmhQ8mTJ30JiFIlP9Ea07fo7BeZ76x4vHiRQ4Es=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fcrt.sh%2F%3Fid%3D287530764

I noticed that a new certificate for a different domain, but with that same 
private key has been issued:
https://clicktime.symantec.com/a/1/UztZ9c6dq7VDtqVztbSn0ztsSjdjchyTG87cjFnvYyc=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fcrt.sh%2F%3Fid%3D638323656

I tried to report it to rev...@digicert.com - but that address was replying 
with an error message...

--
Hanno Böck
https://clicktime.symantec.com/a/1/RJ969RojJELZVkzGgzMk2SN78MqUTvCuXRkZHP0djk4=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Fhboeck.de%2F

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/hc7xtvs26hqWeA42At7XWr7eeiDnWj1n6xCl__YKAGc=?d=ixB7K8sQydENLDztiiH7GzNasNJEnDB7wpes6oH2tWqtBdDVXCNxgW2i1bbRkJqfnpl083l3TNcjtWxKIOnVAhGqcaj4ECVGiEq7QWlO6dCRNg4egXdTyDgqHswD4l2_m4Pxk9zUAmYUibMwcefQDsfGGz6sLG1gaRk6PE8ATedNDXFpHXXQ3X8tgqfhhFbzdbK-KZno6DvjAy2fbUKMeoLrt5-JYOYZ8bS3sc4T0z7px58X56Ui0evBkMsOMK0HcSsZX7KQrA-citRM46mkG2lfDnZe3y2yULYPaAArvERnDqmP0WXdYX-QSJiLrUhzXxwplePV8J5cbTa6HEa7_Jf0Ly9DeNwS5NbTtghxbRwAVERGDodw8HVrBfjCPyvF4SdS5kZhpMY%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-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: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

The keys were emailed to me. I'm trying to get a project together where we
self-sign a cert with each of the keys and publish them. That way there's
evidence to the community of the compromise without simply listing 23k
private keys. Someone on Reddit suggested that, which I really appreciated.
I think the main hold up in this plan is, which websites do we want to call
out? 

-Original Message-
From: dev-security-policy

On Behalf Of Peter Bowen via dev-security-policy
Sent: Wednesday, February 28, 2018 12:38 PM
To: Wayne Thayer 
Cc: timx84...@gmail.com; mozilla-dev-security-policy

Subject: Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 11:29 AM, Wayne Thayer via dev-security-policy
 wrote:
> On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy
 wrote:
>
>>
>> Regarding to our investigation they were only able to send the 
>> private keys for those certificates where the CSR / private key pair 
>> were generated within their online private key generating tool. This 
>> has to be the 23k amount of keys which Jeremy received.
>>
>> I am not aware of guidelines of the CA/B forum but keeping 23.000 (!) 
>> private keys at your online platform seems more than alarming and is 
>> careless and the public should be made aware of this fact.
>>
> I agree with this sentiment, but I also think it creates another 
> policy question with respect to DigiCert's decision to revoke due to 
> key
> compromise: were these 23,000 keys really compromised? The BR 
> definition of Key Compromise is:
>
> A Private Key is said to be compromised if its value has been 
> disclosed to an unauthorized person, an unauthorized person has had 
> access to it, or there exists a practical technique by which an 
> unauthorized person may discover its value. A Private Key is also 
> considered compromised if methods have been developed that can easily 
> calculate it based on the Public Key (such as a Debian weak key, see 
> http://wiki.debian.org/SSLkeys) or if there is clear evidence that the 
> specific method used to generate the Private Key was flawed.
>
> In this case it might be reasonable to argue that Trustico was 
> unauthorized (unless their customers agreed to key escrow when using 
> the online key generation tool). However, in the case of a hosting 
> provider reselling certificates for use on their platform, it's 
> required that they hold the private key and we don't consider that a Key
Compromise.

Jeremy's email suggests that the keys were emailed to him.  If this is
accurate, then it is reasonable that they have been "disclosed to an
unauthorized person".  The only other alternative, again assuming Jeremy did
receive the keys, is to determine that he was authorized by the subscriber
to access the keys.

Thanks,
Peter
___
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: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

I agree with the OV, EV, and IV. Admittedly, DV certs, which constitute almost 
all the certs, are relatively new to DigiCert so that's partly where the 
question arises. We identified it as the key holder or the domain holder. 
Hence, we'd revoke with confirmation of a domain validation. The reseller 
could be the subscriber, but I'm not sure how we tell with DV certs. This is 
especially with legacy Symantec customers where we are still trying to 
establish the personal relationship and understand their use cases, 
communication expectations, etc.

-Original Message-
From: Peter Bowen <pzbo...@gmail.com>
Sent: Wednesday, February 28, 2018 12:14 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 9:37 AM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
> Once we were alerted, the team kicked
> off a debate that I wanted to bring to the CAB Forum. Basically, our
> position is that resellers do not constitute subscribers under the
> Baseline Requirement's definitions (Section 1.6.1). As such, we needed
> to confirm that either the key was compromised or that they revocation
> was authorized by the domain holder (the subscriber) prior to revoking
> the certificate. The certificates were not alleged as compromised at that 
> time.

> This raises a question about the MDSP policy and CAB Forum
> requirements. Who is the subscriber in the reseller relation?  We
> believe this to be the key holder. However, the language is unclear. I
> think we followed the letter and spirit of the BRs here, but I'd like
> feedback, perhaps leading to a ballot that clarifies the subscriber in a 
> reseller relationship.

For certs with subject identity information (commonly called IV, OV, and EV 
certs), there is no question about the subscriber.  The Subscriber is the 
entity identified in the subject: "The Subject is either the Subscriber or a 
device under the control and operation of the Subscriber."

For certificates without subject identity information (DV certificates), the 
certificate does not list the subscriber.  However the CA clearly knows the 
subscriber, as the subscriber is the "natural person or Legal Entity to whom a 
Certificate is issued and who is legally bound by a Subscriber Agreement or 
Terms of Use"

In some cases the "reseller" might be the subscriber if the reseller is a 
hosting company and is the one that accepts the subscriber agreement but in 
the traditional reseller model their customer is the subscriber as the 
reseller's customer is the one accepting the subscriber agreement.

Given that DigiCert appears to have contact information for the Trustico 
customers, that suggests that the Trustico customer is likely the subscriber, 
but looking at IV/OV/EV certificates (if any) should tell for sure.

Thanks,
Peter


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: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

The end user agreed to the subscriber agreement, not Trustico. Our analysis 
follows what Peter B. posted – the subscriber is the “natural person or Legal 
Entity to whom a Certificate is issued and who is legally bound by a Subscriber 
Agreement or Terms of Use"—which in this case was Trustico’s customers.  In 
addition, we felt that given (1) the number of certificates Trustico was asking 
us to mass-revoke and (2) the lack of any substantiation of why Trustico 
thought the certs were “compromised,” we needed more information before 
revoking. At the minimum, it warranted alerting the contact for each 
certificate that revocation was imminent.

 

I also agree that there’s no problem with the way or that the keys were 
provided to DigiCert for cert revocation. I certainly don’t want to discourage 
revocation of compromised certs!  My main question is how do you handle these 
things? The process at scale should not be different if a reseller requests 
revocation compared to any other security researcher. The question is how you 
handle the this volume of revocations when its happen? I’ve never received a 
revocation request of this magnitude before so I’m seeking the wisdom of the 
community in what we do.

 

I’m happy to share any of the details I can. 

 

Jeremy

 

 

From: Ryan Sleevi <r...@sleevi.com> 
Sent: Wednesday, February 28, 2018 11:58 AM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

 

 

 

On Wed, Feb 28, 2018 at 12:37 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

On February 2nd, 2018, we received a request from Trustico to mass revoke
all certificates that had been ordered by end users through Trustico.
Unfortunately, the email was not sent to the appropriate certificate problem
reporting channels and did not surface immediately so we're delayed in
sharing the concerns and information. Once we were alerted, the team kicked
off a debate that I wanted to bring to the CAB Forum. Basically, our
position is that resellers do not constitute subscribers under the Baseline
Requirement's definitions (Section 1.6.1). As such, we needed to confirm
that either the key was compromised or that they revocation was authorized
by the domain holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.

 

I think there's a little nuance to this in the general case (e.g. consider 
"Resllers" who are also the hosting provider, and thus constitute the 
Applicant/Subscriber even when they're not the domain holder, but authorized by 
them), but based on this specific case, I think this sounds like a correct 
determination.

 

I think the biggest question is who agreed to the terms - Trustico or the 
end-user - and that mostly impacts the rest of the decision here. Further, did 
Trustico warrant on behalf of the user that the user agreed to the terms (in 
which case, I would think it's a bit of a copout, and it's really Trustico 
agreeing, thus the Subscriber), or did DigiCert have direct communication with 
the user on the basis of Trustico's introduction (in which case, yeah, the 
Subscriber is the user)

 

Anyway, just highlighting it here as perhaps not a uniform consensus, but 
perhaps not as material as what follows.

 

On 2/27/2018, at my request for proof of compromise, we received a file with
23k private keys matched to specific Trustico customers. This definitely
triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
Once we received the keys, we confirmed that these were indeed the matching
private keys for the reported certificates. We will be revoking these
certificates today (February 28th, 2018).

 

I think all of this sounds reasonable, no different than a security researcher 
(or random member of the public) who were to claim compromise with no evidence 
of that.

 

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.

 

For the same reason that "Jane Random User" should not be able to cause 
revocation merely by assertion, I think that sounds reasonable.

 

This raises a question about the MDSP policy and CAB Forum requirements. Who
is the subscriber in the reseller relation?  We believe this to be the key
holder. However, the language is unclear. I think we followed the letter and
spirit of the BRs here, but I'd like feedback, perhaps leading to a ballot
that clarifies the subscriber in a reseller relationship.

 

I think the question here is less about who is the Applicant, but who is the 
Applicant Representative

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

I believe transparency is the best policy.  I think it'd be helpful to the 
community if we could post the email exchange about the revocation. We can 
redact the agreement termination portions if you'd like, but that'd give a lot 
more clarity around what's going on. Do I have your permission to post those 
emails?

-Original Message-
From: dev-security-policy 
 On 
Behalf Of google.manager--- via dev-security-policy
Sent: Wednesday, February 28, 2018 11:54 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: How do you handle mass revocation requests?

Jeremy,

Today many of our customers experienced lengthy delays when attempting to 
contact us via phone, e-mail and live chat. The reason for the delays were due 
to an unexpected e-mail that DigiCert sent to our customers containing some 
inaccurate information. We were not informed that the e-mail would be sent and 
were caught by surprise. We had disabled this e-mail within your control panel 
and opted to send our own notices, though you took it upon yourselves to send 
my personal details to 20,000 customers.

We didn't authorise DigiCert to contact our customers and we didn't approve the 
content of their e-mail. At no time had any private keys been compromised, nor 
had we ever informed to you that any private keys had been compromised. During 
our many discussions over the past week we put it to you that we believe 
Symantec to have operated our account in a manner whereby it had been 
compromised. Your usage of the word compromise has been twisted by you to your 
benefit and is absolutely defamatory.

We believe the orders placed via our Symantec account were at risk and were 
poorly managed. We have been questioning Symantec without response as to 
concerning items for about a year. Symantec simply ignored our concerns and 
appeared to bury them under the next issue that arose.

There are a range of issues that Trustico intends to investigate via legal 
means.

In good conscience we decided it wasn't ideal to have any active SSL 
Certificates on the Symantec systems, nor any that didn't meet our stringent 
security requirements. Our concerns also relate to the upcoming distrust of all 
Symantec SSL Certificate brands within Google Chrome and the reasoning behind 
it. The same management team responsible for that situation is duly employed at 
DigiCert and are fully managing our account, causing grave concern on our part 
as it appears to be business as usual with a new name. We were also a victim 
whereby Symantec mis-issued SSL Certificates owned by us, subsequently we were 
asked to keep the matter quiet, under a confidentially notice.

We had implemented a system to ensure that all customers would receive a 
replacement SSL Certificate, though today it had failed to perform this 
function.

In our view it is absolutely critical that an SSL Certificate performs its 
intended function. Symantec's issue with Google appeared to seal that deal, 
whereby they will all eventually fail due to distrust. In accordance with CAB 
Forum guidelines we acted to immediately revoke active SSL Certificates whereby 
trust was questionable.

Trustico absolutely distrusts the Symantec brand due to the issues that forced 
Symantec into having to hand over its entire authentication business to an 
alternate CA and a range of issues beforehand. Though, Symantec was ultimately 
acquired by DigiCert - though now DigiCert appears to be influenced by the 
Symantec management team - that to date still is managing our account. Trustico 
stopped offering the Symantec brands early February after a meeting with your 
Symantec management team, whereby they had disclosed to us that various 
reckless issues had occurred (recording available).

We realize that this mass revocation is bothersome and time consuming for all 
that have been affected. We're working to contact all customers to get orders 
replaced as priority and working through a backlog of enquiries. 

Unfortunately, things didn't go very well for us today and we are extremely 
sorry for all the confusion and inconvenience that has been caused. We were 
relying on systems that would easily replace and issue SSL Certificates 
automatically, though that didn't occur and we ended up in quite a mess. 
DigiCert didn't work with us to understand the issues and resolve them, we felt 
we were at a dead end.

We'll be following up again shortly with an update surrounding what occurred 
and more information about where we experienced failures. In the meantime, our 
staff are concentrating on getting SSL Certificates issued as quickly as 
possible from a reputable and trusted CA.

As for the question of who is the subscriber, well ultimately that came down to 
the agreement that we had made with you and the agreement on the website. The 
conditions of the subscriber agreement were not honoured by you when it came to 
our requests anyway 

Re: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

No. Just the 23k. Part of the reason I posted to the Mozilla list are open 
questions about whether Trusticos request is sufficient to trigger the br 
requirements. My gut is no, and sounds like the browsers agree.  We’ll only 
revoke the remaining 27k if we receive evidence of compromise

On Feb 28, 2018, at 2:52 PM, jomo 
<mozilla-li...@jomo.tv<mailto:mozilla-li...@jomo.tv>> wrote:


Basically, we're revoking 50k people without
being able to explain why (well, other than the key was compromised).

Unless I misunderstood, you originally said you received 23k compromised keys 
and are revoking those.

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.


Has DigiCert received proof of compromise of all 50k in the meantime?


On 28.2.18 22:42, Jeremy Rowley via dev-security-policy wrote:

We don't have a process to prevent third parties from storing private keys.
I'm not sure how that would even work considering the approved third-party
use cases vs. non-approved use cases.  In fact, I'd postulate there's
nothing wrong with Trustico holding the private keys if they were hosting
the site or providing CDN services for all of these sites. The issue is
Trustico alleged compromise of the certificates and sent us the private keys
believed compromised in support. There were a lot of them.

This is a mass revocation without any explanation of what went wrong or why.
The reseller mentioned and proved compromise, but there's no way to see if
what happened, whether the issue was mitigated, or how it's going to be
prevented from happening again. Basically, we're revoking 50k people without
being able to explain why (well, other than the key was compromised).

-Original Message-
From: dev-security-policy
<dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org><mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org>
On Behalf Of urijah--- via dev-security-policy
Sent: Wednesday, February 28, 2018 2:24 PM
To: 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: How do you handle mass revocation requests?

Is Trustico's storage of private keys related to this security report from a
few months back (which did not appear to ever have been fully
investigated...)?

https://clicktime.symantec.com/a/1/gUJtIwxyRazHoxd9FIcS40cx3EykeGjrwv4urOpHj
u0=?d=-1kl6pTbi8aU0HfRh9ZNP86TCSEsjm5TvumKZsLlfO6tgKV5N4_MitDAK64FGwutmiXu3D
eTelMEfv3ep7X8kj6GIwMY8tUVM_WKGkqW_uhm0fHWgY9ZwlUytCHVYb_1WWceLMVi9w9Ec7h3sH
G1wIJHWNk2L8RcVycGdrIGRFvV76QXqOck9szIT1MqOPD6gSaSZRnxp-ItDtBU5xSit2RwQjv5sB
Ln2qFtnD9T_wuM6-KAeTUDm1O51uIY3NpT-q5hyIKG5YG-Ds6a9ceM0JgMrLhM3evdd-BmO3e6eP
1fXZXAQgJCZ_A7SnTbSagjzHzUVC65PN3AnrdJ6ANhZAwjjCdHdbjOeIqwInT-oFJ8lufSzaBeui
OECQuf-IqhCnfsam6KnTGT5k-aQlG_BjOW8fny0TS21Upa4k4aX2Xm7es0oRfOUS-OxAQLVKCGg-
cER_Pj3TmyKGPFFw_SzUky=https%3A%2F%2Fgroups.google.com<http://2Fgroups.google.com>%2Fd%2Fmsg%2Fmozilla
.dev.security.policy%2FCEww8w9q2zE%2FF_bzX1guCQAJ

Does Digicert have (or will it have) some sort of process in place to
prevent resellers from storing private keys so casually?

On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote:


Hi everyone,



I wanted to share an incident report regarding the revocation of
certain certificates ordered through a reseller.



On February 2nd, 2018, we received a request from Trustico to mass
revoke all certificates that had been ordered by end users through


Trustico.


Unfortunately, the email was not sent to the appropriate certificate
problem reporting channels and did not surface immediately so we're
delayed in sharing the concerns and information. Once we were alerted,
the team kicked off a debate that I wanted to bring to the CAB Forum.
Basically, our position is that resellers do not constitute
subscribers under the Baseline Requirement's definitions (Section
1.6.1). As such, we needed to confirm that either the key was
compromised or that they revocation was authorized by the domain
holder (the subscriber) prior to revoking the certificate. The


certificates were not alleged as compromised at that time.




Later, the company shared with us that they held the private keys and
the certificates were compromised, trying to trigger the BR's 24-hour
revocation requirement.  However, we insisted that the subscriber must
confirm the revocation request or there must be evidence of the private


key compromise.




Normally, we permit partners to revoke and manage the certificates
freely on behalf of their customer, with DigiCert providing all
validation and issuance services. However, the sheer number of
revocation requests (50k) and allegation of compromise triggered
concerns around the

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

Yep - that was you. Thanks a ton. We posted 10 CSRs so far. Is this what you
were thinking? 

-Original Message-
From: Nick Lamb <n...@tlrmx.org> 
Sent: Wednesday, February 28, 2018 2:37 PM
To: dev-security-policy@lists.mozilla.org
Cc: Jeremy Rowley <jeremy.row...@digicert.com>
Subject: Re: How do you handle mass revocation requests?

On Wed, 28 Feb 2018 20:03:51 +
Jeremy Rowley via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:

> The keys were emailed to me. I'm trying to get a project together 
> where we self-sign a cert with each of the keys and publish them.
> That way there's evidence to the community of the compromise without 
> simply listing 23k private keys. Someone on Reddit suggested that, 
> which I really appreciated.

That's probably me (tialaramex).

Anyway, if it is me you're referring to, I suggested using the private keys
to issue a bogus CSR. CSRs are signed, proving that whoever made them had
the corresponding private key but they avoid the confusion that comes from
DigiCert (or its employees) issuing bogus certs.
Everybody reading m.d.s.policy can still see that a self-signed cert is
harmless and not an attack, but it may be harder to explain in a soundbite.
Maybe more technically able contributors disagree ?


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

Fwd: [cabfpub] How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

Posted to cab forum accidentally instead of Mozilla dev


Begin forwarded message:

From: Jeremy Rowley 
>
Date: February 28, 2018 at 2:33:41 PM MST
To: Ryan Sleevi >, Geoff Keating 
>
Cc: CA/Browser Forum Public Discussion List 
>
Subject: RE: [cabfpub] How do you handle mass revocation requests?

Here’s 10 CSRs that people can correlate with the CT logs. I’ll create another 
100 or so to dispel any doubt.

-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMamagziY67jAV1XWBT2UBudz8leqPeZ
nMGCP9Sct2qc5tDDLz34QIMFO9mv4eDRduMOTG7rwQygKPvI0mAKzKDJCxUvKLYJ
Th/IALgkHfSvv7UzXUxF2kxviuvTCoP0Oee3DUJl4V614R2BnEtEpjEC4WNZglIU
ytQiX36u4WQEbU1LGxp16+Rqz55TOnqRaUNlCCVjB99A3dvxYxpa+6qUHt2aeEyW
WBguBq4sDzOeeLCcnfiCywbDKD4YeqQxvn1EJGBrCQnOf5UdHidJB3ZKKngYWKaZ
48nYK2CqM1dq44vIH6EezGq+0Xs8EFJfi2mjDghfziiX1UtpUt2/vUcCAwEAAaAA
MA0GCSqGSIb3DQEBCwUAA4IBAQA/HM907Hc/rV+olpHW8n1N0UkhfbVHjSegFhQZ
2Wn4jFKAargvOCGDChThcnUbquptKpTFVaKJap0JB2T+fCI3WAMPG8CJKakcOjG/
ZKheN3fNGUiaNk/Wyh/f6XnhWbchIK2OpcsSUAA5ju14bqs2epWl17c0MBPVY5sJ
wFIBrNVjqji3Zkf7aE9GSMx36d8swfhqwomvFvO5SGKspPm2eRpBPwi8lRORDxz3
cAoG4TU3/7xs2XAyTE27UQwdrUo7jkVUlCFoWf6DySHEy7CKTz3Vwu9ABtNdBtG9
oEnWxhIhBPcYOwCrGkiJGuRImFAfLifHWvLUNqGKpz/nEr+c
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICvDCCAaQCAQAwdzELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEcMBoGA1UECxMTUHJvb2Ygb2Yg
Y29tcHJvbWlzZTEYMBYGA1UEAxMPd3d3LmV4YW1wbGUuY29tMIIBIjANBgkqhkiG
9w0BAQEFAAOCAQ8AMIIBCgKCAQEAqS0TSQbsGiJdAYfhuNrGzvXX4XvwToLBq+Hx
trxKq8zoWIRtimRuH66uRmVy0I/lR78u4FEewAjblaS+v1jTLNopik+taBiFHudn
/RGliOcKFohp4BYZuSZRRt3uLN5z8Jr5VbRMzZy6SNp3wX3f+Ie/XsAV04TXmbSv
+V8ZUjxzj1448DsCFL1NNDUcoic/MUcW+fsu9VuxhdETOwrf7CgJ91FgzwHHSMKL
Mq6DwY6xF90KQ5vInhYhRQ447zoSW1ABnmF+gPxDjXXb5pCh4aua8wOv3AmiZbbn
Nnkv9y1YXIeBJ1o1zbTt51v62Qu4LeRYVfWjhI1sn8k96DH8mQIDAQABoAAwDQYJ
KoZIhvcNAQELBQADggEBADgA4tGSyIpAA9uXooQivo9NH7lZH+M4bXpn+nOmNxn/
aRzmbg9NksRKrQoN0/CkWpiu6vwp31gAG2eIpnvNX9ltzPD2/yHAQCLUZmiGZnUP
fUdV1t7Z1EZ9Mj7YmlAN5NuQPAu7SL5fZ8UJSzzY1H7AuECU29j81dK2jLxRR1p6
PaajUGPAvraVTZND4JGQJpIazrF+mVDADdt1aOntr6lj+CC92E5oQxCWtU8uUX7Y
k5OJdewmNlVIk7wtcuVA2ju3jFlNtHP66DE/UDlcx5X5vE2qFq3aZFAqUAf0XXWW
bagqqjxfHSQaNVGlWBkJb0eCdD+DW8IK0nuw5GP2rzY=
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfZnCmYERBmZPEMdK5yvvC0QXjB1FQo
bu4IC9W1ThdFySkJL6t2MeoxbaTW8hwdATf8JHlRnrpevXStUsYDZShxpsQePZk8
LUW5OHQ6W/XDbGo4tC69Q3XTYvLeX+3q971mbiyFpBondTKZaKZYAR5omV7e/Olt
ZzN1yqyX551NsSwDGTrgBqCU2XQzYu9Tl9Nibjl4yCKCG9/JbgGa+gy8j1eKWxIt
lW7jmJID8s0N2v0ed1lvxr7A3oCiYef4TSi2RjLyZThGw1a7j3QqlBeGIqo89XtG
8GxA2nNSGx7gnIceMGGUd0q9iGQl1gc+FOI5oBbyjLcMCty2YInMQucCAwEAAaAA
MA0GCSqGSIb3DQEBCwUAA4IBAQBQyDCiBYXRMOryHhVVW52kY6wvsgWsPXLR0piQ
FJKP/drPdqgs/uxY6Nx163sNaiWPEI0tUWSmnuPe43qAyIqJXmnd/C6EqGy+ZI1Y
lf0XAfqVzJ+tc9639pSkGfeGxU75qdPwWqbwzEEdNZCDR/4QqzhGgMLyvH7icoc0
7ikxxwyUiKpP4h3nAV7Fg4EMKeEn/3m+vM0aGnZNx16WHpQF/VnyBM8NimADmO/u
vywC2TbLNBYYYG7dlLUk7fYfoFY5okel4z2fjmaNhuQQEpffJ366DC41A3fWDgp8
j1Ok8PfhiVySEwdSCNgpZbHnSwxodk4E3aZ22kCa2f7nOzDd
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBALjEWXaHdMifi0LbL0GrnYV6uoltTicU
ywDOkSz/cReCI6gzxb1jpuQu1iVAkmiZUmPk4sPjc4e/OvAo0IyXgVEqBVcB4cmB
JTdWFj4fde8G9/NWoKIHIRVS4envx4jjRFEh6uDI9o4pDcpfvjh59s1RCjqU9EqX
DueUoKCk7eynjBxePNYZtZL5xBbBRIeqkjtBALtdnQdkbMTBAHJT4WvK2y9ExtWY
aJAoAf0ZYmQOeqzXZC4w1FKs7/GEa1qaPjyxe596LvZvOMZbB49gUYou6lhmG+ga
PaJIGm53/A4PgLnCisEjrVL46YB/k/EzTQtwq5jRg5usIL0/YCJlvCkCAwEAAaAA
MA0GCSqGSIb3DQEBCwUAA4IBAQCgCziprbbD+aS22QHBMOnjy5r7iYiteKO1uB1o
zdaKpNBg32+tNyYsNazijAb0rcyFLGAeTfjbWQ5YDbK44qGmKxhO5nyeUkb9/ulI
scT94Trwu8j77DTxaFNTziETbw5KIBfiC7M5cD+vQ2UexJ8giv9s7ZchXY/hK8TA
IPY1jfEzioEgjap2bXhZ7GGHhjNg/3DIHCy2dD+eDeTsHhZQ+4ndfMeydg9fn6se
20A73X5rFGYKtp3z19stTDjXFDVyf/ngXtyti830ebQgmxRLJRAKV+MSHrdxW4Jj
qkuW6fmTj2s3x8iTKecd5Q/NOKt2XjOMldc6eKA4VSi3QNuc
-END CERTIFICATE REQUEST-
-BEGIN CERTIFICATE REQUEST-
MIICwDCCAagCAQAwezELMAkGA1UEBhMCVVMxDTALBgNVBAgTBFV0YWgxEDAOBgNV
BAcTB05ld2J1cnkxDzANBgNVBAoTBkplcmVteTEgMB4GA1UECxMXUHJvb2Ygb2Yg
a2V5IGNvbXByb21pc2UxGDAWBgNVBAMTD3d3dy5leGFtcGxlLmNvbTCCASIwDQYJ

RE: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

1) Not all of the certificates being revoked use the Symantec hierarchy.
There are some certs that use the DigiCert replacement hierarchy. Not many
though.
2) Sorry my wording was strange.  It almost always is.  What I meant, is
Trustico specifically asked for the certs to be revoked within 24 hours as
required by the BRs. They said in the email they were triggering the 24 hour
requirement. 
3) I really feel like a third point would be important, but I can't think of
one. 

-Original Message-
From: dev-security-policy

On Behalf Of Matthew Hardeman via dev-security-policy
Sent: Wednesday, February 28, 2018 3:23 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

On Wednesday, February 28, 2018 at 3:55:37 PM UTC-6, Ryan Duff wrote:
> >From what I've read, it appears the situation here is that Trustico
wanted to revoke all their customer certs from Digicert so they could do a
mass migration to another CA (which is not a proper reason to revoke). When
asked for proof by Digicert that the certificates were compromised and
needed to be revoked, Trustico sent Digicert 23,000(!) private keys that
*they had stored* due to the fact that they were generated by their
web-based system in order to effectively *make them* compromised.
> 
> Am I missing anything?

That's kind of what I was thinking happened also.

Though a couple points to correct:  The original issuing CA hierarchy is a
Symantec trust path.  This suggests that what they really wanted to occur
was to trigger a 24 hour reissue of all of these certificates under a
DigiCert trusted path -- since presumably any issuance at this point would
fall under a DigiCert path.

Thus, within 24 hours, getting new certificates for all their customers
under the new trust path.  I'm going to guess someone at Trustico was
getting annoyed at support calls regarding the migration and somehow assumed
there'd be no consequences for pushing the issue by way of getting all those
certificates revoked on "security" grounds.

As grounds for this belief, I submit the strangely worded statement of Mr.
Rowley at the start of the thread "Later, the company shared with us that
they held the private keys and the certificates were compromised, trying to
trigger the BR's 24-hour revocation requirement".

That language seems to imply that there's a sense that the security / web
PKI integrity aspect is less the matter at stake and more that the keys were
located and sent over to create an impossible to ignore security issue
forcing the 24 hour window.

My guess is that the person at Trustico wanted immediate reissuance of all
of the Symantec certificates under the DigiCert trust paths and assumed:

1.  That revoking the certs for security reasons would result in ASAP
reissue (probably true in one-offs).
2.  That the reissuance would happen in the DigiCert trust path (almost
certainly true).
3.  That they'd have a spike of support issues related to the reissuances,
but that Trustico would have more control over the period over which they
had to help customers migrate certificates and then the "bleeding" would
stop.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/1SicdYM5NOSV8S29ZlemtDgUftWWe-mEnCeFfDCfA
lw=?d=paMnJZlER7IHb626K-31V2u-Kf4DBs2hoO7Bro78ZuywH3EZ9N1dve7JXTCFPZFHyQrvw7
cDEqjPm1CCO0iQqqCbe-J7q2_uVOXTQzSslJpmeaUe9RmpgB81xaobKJOyb_YpAY8IOdkE832w7N
tu7J94BmAMUFyIN-LINYJhcdKrmRggiP3dwENTjoH8GFBgeJgbAAJ7AXEY8EsaOLt-dqVymUiml9
GCqK8Pz2bZYq21i2TjrlH5i5ctTnHGcaJLrBukwohzJ1XA0B0Ma6sfh6NdDO9yi3psZCXUIDcZyp
5FtLBoYtTo6DUQVC8VhfOJY6KGhSpursgUnQdy6yQRtirjLO9kmIOKJSuJvlbaKD3gYKkxIRzMLA
6jPbVCxU77Z6q6OAnzLtAIRiCe7-MVzty2jFdcG8R9uiVI7Vf241-3ANcBFbr288JrDaZYHwhYJu
rWo3wUC3HNJXFV_nf74MJE=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-se
curity-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: How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

We don't have a process to prevent third parties from storing private keys.
I'm not sure how that would even work considering the approved third-party
use cases vs. non-approved use cases.  In fact, I'd postulate there's
nothing wrong with Trustico holding the private keys if they were hosting
the site or providing CDN services for all of these sites. The issue is
Trustico alleged compromise of the certificates and sent us the private keys
believed compromised in support. There were a lot of them. 

This is a mass revocation without any explanation of what went wrong or why.
The reseller mentioned and proved compromise, but there's no way to see if
what happened, whether the issue was mitigated, or how it's going to be
prevented from happening again. Basically, we're revoking 50k people without
being able to explain why (well, other than the key was compromised). 

-Original Message-
From: dev-security-policy

On Behalf Of urijah--- via dev-security-policy
Sent: Wednesday, February 28, 2018 2:24 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: How do you handle mass revocation requests?

Is Trustico's storage of private keys related to this security report from a
few months back (which did not appear to ever have been fully
investigated...)?

https://clicktime.symantec.com/a/1/gUJtIwxyRazHoxd9FIcS40cx3EykeGjrwv4urOpHj
u0=?d=-1kl6pTbi8aU0HfRh9ZNP86TCSEsjm5TvumKZsLlfO6tgKV5N4_MitDAK64FGwutmiXu3D
eTelMEfv3ep7X8kj6GIwMY8tUVM_WKGkqW_uhm0fHWgY9ZwlUytCHVYb_1WWceLMVi9w9Ec7h3sH
G1wIJHWNk2L8RcVycGdrIGRFvV76QXqOck9szIT1MqOPD6gSaSZRnxp-ItDtBU5xSit2RwQjv5sB
Ln2qFtnD9T_wuM6-KAeTUDm1O51uIY3NpT-q5hyIKG5YG-Ds6a9ceM0JgMrLhM3evdd-BmO3e6eP
1fXZXAQgJCZ_A7SnTbSagjzHzUVC65PN3AnrdJ6ANhZAwjjCdHdbjOeIqwInT-oFJ8lufSzaBeui
OECQuf-IqhCnfsam6KnTGT5k-aQlG_BjOW8fny0TS21Upa4k4aX2Xm7es0oRfOUS-OxAQLVKCGg-
cER_Pj3TmyKGPFFw_SzUky=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla
.dev.security.policy%2FCEww8w9q2zE%2FF_bzX1guCQAJ

Does Digicert have (or will it have) some sort of process in place to
prevent resellers from storing private keys so casually?

On Wednesday, February 28, 2018 at 12:38:16 PM UTC-5, Jeremy Rowley wrote:
> Hi everyone,
> 
>  
> 
> I wanted to share an incident report regarding the revocation of 
> certain certificates ordered through a reseller.
> 
>  
> 
> On February 2nd, 2018, we received a request from Trustico to mass 
> revoke all certificates that had been ordered by end users through
Trustico.
> Unfortunately, the email was not sent to the appropriate certificate 
> problem reporting channels and did not surface immediately so we're 
> delayed in sharing the concerns and information. Once we were alerted, 
> the team kicked off a debate that I wanted to bring to the CAB Forum. 
> Basically, our position is that resellers do not constitute 
> subscribers under the Baseline Requirement's definitions (Section 
> 1.6.1). As such, we needed to confirm that either the key was 
> compromised or that they revocation was authorized by the domain 
> holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.
> 
>  
> 
> Later, the company shared with us that they held the private keys and 
> the certificates were compromised, trying to trigger the BR's 24-hour 
> revocation requirement.  However, we insisted that the subscriber must 
> confirm the revocation request or there must be evidence of the private
key compromise.
> 
>  
> 
> Normally, we permit partners to revoke and manage the certificates 
> freely on behalf of their customer, with DigiCert providing all 
> validation and issuance services. However, the sheer number of 
> revocation requests (50k) and allegation of compromise triggered 
> concerns around the impact to the web and browser users. Therefore, 
> this was categorized as high risk, especially considering the relationship
between Trustico and DigiCert is terminating.
> 
>  
> 
> On 2/27/2018, at my request for proof of compromise, we received a 
> file with 23k private keys matched to specific Trustico customers. 
> This definitely triggered our 24-hour revocation processing requirement
under 4.9.1.1.3.
> Once we received the keys, we confirmed that these were indeed the 
> matching private keys for the reported certificates. We will be 
> revoking these certificates today (February 28th, 2018).
> 
>  
> 
> At this time, Trustico has not provided any information about how 
> these certificates were compromised or how they acquired the private 
> keys. As is standard practice for a Certificate Authority, DigiCert 
> never had possession of these private keys.
> 
>  
> 
> Currently, we are only revoking the certificates if we received the 
> private keys. There are additional certificates the reseller requested 
> to have revoked, but DigiCert has decided to disregard that request 
> until we receive proof of compromise or more information 

RE: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Jeremy Rowley via dev-security-policy]

Thanks Alex. Sorry for the delayed response. I've been traveling today.
We're reaching out to each of the customers and getting their cert replaced.


Looking into this, we did not correctly implement the ballot:
1. We didn't add a check to our backend system too verify the cert included
a descriptor prior to issuance. 
2. On the front end, we missed requiring a Tor descriptor prior to
processing the order. 
3. The validation team received insufficient training on the Tor descriptor
requirement. 

In reality, the issue was too much reliance on the human component of
asserting the Tor descriptors instead of having a technical control in
place. We're working on putting those technical controls in place.  

Jeremy

-Original Message-
From: dev-security-policy

On Behalf Of Alex Cohn via dev-security-policy
Sent: Sunday, March 11, 2018 9:37 PM
To: dev-security-policy@lists.mozilla.org
Subject: DigiCert .onion certificates without Tor Service Descriptor Hash
extension

In the EV Guidelines [1], Appendix F states "The CA MUST include the CAB
Forum Tor Service Descriptor Hash extension in the TBSCertificate convey
hashes of keys related to .onion addresses." This language was added in
Ballot 201 [2], which had an effective date of 8 July 2017.

The following certificates (and precertificates if the corresponding
certificate is not in a public CT log) were issued by DigiCert after 8 July
for .onion domains, but lack the necessary extension:
https://crt.sh/?q=240277340 (revoked 26 October 2017)
https://crt.sh/?q=261570255
https://crt.sh/?q=261570338
https://crt.sh/?q=261570380
https://crt.sh/?q=261570384
https://crt.sh/?q=261579788
https://crt.sh/?q=261601212
https://crt.sh/?q=261601280
https://crt.sh/?q=261601281
https://crt.sh/?q=261601284
https://crt.sh/?q=261988060
https://crt.sh/?q=326491168
https://crt.sh/?q=326830043
https://crt.sh/?q=328308725
https://crt.sh/?q=328961187
https://crt.sh/?q=329559222
https://crt.sh/?q=330180704
https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email to
DigiCert)

This was previously discussed on m.d.s.p about a year ago [3].

[1]
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.
8.pdf
[2] https://cabforum.org/2017/06/08/2427/
[3]
https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/ZtNI
D_xfAgAJ
___
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: Mozilla Security Blog re Symantec TLS Certs

[Jeremy Rowley via dev-security-policy]

Same question. Does this mean the key used to sign the digicert roots is 
subject to the distrust without exception?

> On Mar 13, 2018, at 1:36 PM, Kai Engert via dev-security-policy 
>  wrote:
> 
>> On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote:
>> Wayne and I have posted a Mozilla Security Blog regarding the current
>> plan for distrusting the Symantec TLS certs.
>> 
>> https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/
> 
> Hello Kathleen and Wayne,
> 
> the blog post says, the subCAs controlled by Apple and Google are the
> ONLY exceptions.
> 
> However, the Mozilla Firefox code also treats certain DigiCert subCAs as
> exceptions.
> 
> Based on Ryan Sleevi's recent comments on this list, I had concluded
> that the excluded DigiCert subCAs are used to support companies other
> than Apple and Google. Is my understanding right or wrong?
> 
> Are Apple and Google really the only beneficials of the exceptions, or
> should the blog post get updated to mention the additional exceptions?
> 
> Thanks
> Kai
> ___
> 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: Transforming a trade name into ASCII in the O field of an OV cert

[Jeremy Rowley via dev-security-policy]

That is correct. We use transliteration of non-latin names through a system
recognized by ISO per Appendix D(1)(3)

-Original Message-
From: dev-security-policy

On Behalf Of cbonnell--- via dev-security-policy
Sent: Tuesday, April 24, 2018 7:12 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Transforming a trade name into ASCII in the O field of an OV
cert

On Monday, April 23, 2018 at 3:34:38 PM UTC-4, Wayne Thayer wrote:
> Section 9.2.1 of the EVGLs is stricter, only permitting abbreviations. 
> If this were an EV cert I would argue that it was misissued.
> 
> On Mon, Apr 23, 2018 at 12:13 PM, Ryan Sleevi via dev-security-policy 
> < dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Mon, Apr 23, 2018 at 1:11 PM, Henri Sivonen via 
> > dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> >
> > > First, it seems to me that the Baseline Requirements allow 
> > > transformations of the organization's name only if the CA 
> > > documents such transformations. I am unable to find such 
> > > documentation in DigiCert's CP and CPS documents. Am I missing
something?
> > >
> >
> > At present, these are not required to be in the public documentation.
> > Merely, the requirement is that the CA "documents" - i.e. it is 
> > presently acceptable to only include this documentation in 
> > information provided to the auditors.
> >
> >
> > > Second, while verifying that the applicant indeed represents a 
> > > specific real organization is a difficult problem, in the case 
> > > where the country that the certificate designates operates an 
> > > online-queryable database of registered businesses, associations, 
> > > etc., it should be entirely feasible to eliminate the failure mode 
> > > where the certificate's organization field is (absent documented 
> > > transformations permitted under the Baseline Requirements) not 
> > > canonically equivalent (in the Unicode sense) to the name of any 
> > > organization registered in the country that the certificates 
> > > designates. That (inferring from the certificate for
> > > www.alandsbanken.fi) there isn't technical process that would by 
> > > necessity remove diacritical marks from the organization field and 
> > > that the certificate for www.saastopankki.fi has them removed is 
> > > strongly suggestive that DigiCert's process for validating 
> > > Finland-based organization does not include as a mandatory part 
> > > either the retrieval of the organization's name via an online API 
> > > to the business registry or a human CA representative copying and 
> > > pasting the organization's name from a browser view to the business
registry.
> > >
> >
> > The Baseline Requirements do not dictate the datasource used in 
> > various jurisdictions. Thus even when there is a canonical source 
> > through legislation, the BRs do not require its use.
> >
> >
> > >  I wonder: When a given country
> >
> > has an online-queryable business registry, why isn't it either
> > > recommended or required to import names digitally from the 
> > > business registry into certificates? Such practice would eliminate 
> > > the failure mode of the certificate designating a name that 
> > > doesn't match any entry in the business registry for such country. 
> > > (Obviously, if it was _required_, the BRs would need to include a 
> > > list of countries whose business registry is considered 
> > > online-queryable in the sense that the requirement would apply, 
> > > but unwillingness to maintain such a list does not explain why it 
> > > isn't even recommended.)
> > >
> >
> > "Recommended" is pointless. Required is the only thing that makes 
> > sense, and the complexities and overhead involved precisely explain 
> > why it isn't required.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://clicktime.symantec.com/a/1/BvQKGKG-atiF6qzY2ACOk9yeXt5fmZNpd
> > -faQX5l0PY=?d=0s1t1MPwIPG9XkHuYF2WEA8S7E5P0how6g9pm8AbMsID3Vu4VG4b4d
> > cVTpsXAtxoPHgF9wjrujQ0OOr4Qn6NNec-jNZYeJoVX5m6FtONVBOqnpptVuxrSnbzbN
> > mjtVrSrgW9MjFpB_PV_GA0a6d9CDPW00YSAN5s19pKxQFY4khaGT4tGsNBPV82wJ57B-
> > 0V-gd5e-1RY-WPPfqqiSVefSEHM3CbmoTYvMcDfItqF15BC0QZabSo1qReVcnLtpkA07
> > NalO1afKP9pBC8NHIaF2qytDuUbZ-0_7wZVecDePdhfK4ghowJT_2N6v2KHnCG1cElhU
> > 822SsjxhXhwrQTBMTCLXhqVFTQqZtfPfRLDYzl0PcS-PLbsh2A96Dr_Y2gQ_rxoeIKIc
> > z5ln_0I189aAACvwnBtEFieiU0dIZxR3_s0ZN8Zp7MAS_0DY8i7xp0YGMCEiaC-X0rpJ
> > 5VXKItovyxmoIN7_63_vr5ObrP47_KLALVV-eG2OCX=https%3A%2F%2Flists.moz
> > illa.org%2Flistinfo%2Fdev-security-policy
> >

Appendix D of the EV Guidelines
(https://clicktime.symantec.com/a/1/k5LVvsTsn1aOD8kIgUl5TxWF-s1BWAyIy_p_gHjK
8OE=?d=0s1t1MPwIPG9XkHuYF2WEA8S7E5P0how6g9pm8AbMsID3Vu4VG4b4dcVTpsXAtxoPHgF9
wjrujQ0OOr4Qn6NNec-jNZYeJoVX5m6FtONVBOqnpptVuxrSnbzbNmjtVrSrgW9MjFpB_PV_GA0a

RE: RAs and the BRs

[Jeremy Rowley via dev-security-policy]

A reasonable control can include contractual controls, thus 6.6 is solved 
simply via contract with the CA. Section 8.7 does give some control (and I 
missed that when going through this the first time), but the audit criteria is 
only that the CA reviews a 3% sample. As long as I documented that I review the 
RA practices and did the 3% review (regardless of the results), then the CA 
escapes oversight on its validation process. 

 

 

From: Wayne Thayer <wtha...@mozilla.com> 
Sent: Wednesday, April 18, 2018 1:18 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>
Subject: Re: RAs and the BRs

 

On Tue, Apr 17, 2018 at 9:21 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

There is a way to get zero-validation certs, totally legit, under the BRs.
Currently, the BRs permit pretty much free delegation of Registration
Authorities for everything except domain verification. Without RA audit
requirements or even a requirement that the CA monitor/control the RA, the
cynical-side of me doubts whether the verification is enforced without the
CA first receiving a third-party complaint. Section 1.32 permits free RA
delegation if the verification requirements are met by the process as a
whole and that a contract exist between the delegated third party to do the
following:"(1) Meet the qualification requirements of Section 5.3.1, when
applicable to the delegated function; (2) Retain documentation in accordance
with Section 5.5.2; (3) Abide by the other provisions of these Requirements
that are applicable to the delegated function; and (4) Comply with (a) the
CA's Certificate Policy/Certification Practice Statement or (b) the
Delegated Third Party's practice statement that the CA has verified complies
with these Requirements.". Essentially, as long as there is a) a contract
between the CA and RA, and b) the CA is performing domain verification (and
c) no one complains), the RA is free to do whatever the RA deems
appropriate, permitting the CA to circumvent the BRs and audit oversight.
There's no requirement that the CA audit the RA's role in the verification
process or that the RA provide any reporting to the CA or auditors. 

BR section 1.3.2 defines a Registration Authority as a Delegated Third Party. 
Section 8.7 says:

Except for Delegated Third Parties that undergo an annual audit that meets the 
criteria specified in Section 8.1, the CA SHALL strictly control the service 
quality of Certificates issued or containing information verified by a 
Delegated Third Party by having a Validation Specialist employed by the CA 
perform ongoing quarterly audits against a randomly selected sample of at least 
the greater of one certificate or three percent of the Certificates verified by 
the Delegated Third Party in the period beginning immediately after the last 
sample was taken. The CA SHALL review each Delegated Third Party’s practices 
and procedures to ensure that the Delegated Third Party is in compliance with 
these Requirements and the relevant Certificate Policy and/or Certification 
Practice Statement. 

The CA SHALL internally audit each Delegated Third Party’s compliance with 
these Requirements on an annual basis. 

The WebTrust BR audit criteria include a number of controls related to CA 
oversight of Delegated Third Parties, including 6.6:

 

The CA maintains controls to provide reasonable assurance that the CA 
internally audits each Delegated Third Party’s compliance with the Baseline 
Requirements on an annual basis.



Combined with method 1, there is no obligation the CA actually do anything
to vet the customer or obtain any evidence that the customer even exists.
As you all know, method 1 requires only that the CA confirm the WHOIS
information matches the applicant. As long as the WHOIS information matches,
problem solved. As noted above, the RA is not actually required to do any
validation (just say that they do) so if the RA passes over the WHOIS name
as the verified information, the cert will issue without a second glance.  



I realize that method 1 and method 5 are going away (for good reason), but
that doesn't happen until August. I'd be interested in seeing whether
someone can get a cert in this manner from a CA that supports RAs. 



Jeremy 



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: Policy 2.6 Proposal: Require CAs to support problem reports via email

[Jeremy Rowley via dev-security-policy]

I believe the intent of the certificate problem reporting in the BRs is to 
encourage CAs to accept and respond to issues. Although the intent is not 
specifically stated, my reasoning is based on the fact the BRs requiring CAs to 
maintain a 24x7 ability to respond, a 24 hour ability to process certificate 
problems, and a public reporting mechanism. To support this objective, I think 
we should make the process as easy as possible for reporters, including 
mandating email. Finding the email addresses is a pain with little reward. 
Having to go through captchas to even get the email sent is just another 
obstacle in getting the CA a timely certificate problem report.  Therefore, I'd 
adopt Ryan Hurst's proposal and require that the email be in a standardized 
format (no more hunting for email aliases) without any blockers to prevent the 
certificate problem report. Filtering through the mess of emails you get on 
those aliases is the CAs responsibility. 

Jeremy

-Original Message-
From: dev-security-policy 
 On 
Behalf Of Wayne Thayer via dev-security-policy
Sent: Tuesday, April 17, 2018 10:50 AM
To: mozilla-dev-security-policy 
Subject: Policy 2.6 Proposal: Require CAs to support problem reports via email

Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says:
"The CA SHALL provide Subscribers, Relying Parties, Application Software 
Suppliers, and other third parties with clear instructions for reporting 
suspected Private Key Compromise, Certificate misuse, or other types of fraud, 
compromise, misuse, inappropriate conduct, or any other matter related to 
Certificates. The CA SHALL publicly disclose the instructions through a readily 
accessible online means.”

Mozilla has made a central list of these mechanisms in the CCADB [1] but, as it 
turns out, some of them (such as web forms with CAPTCHAs) are difficult to use. 
It is proposed that Mozilla policy go above and beyond the BR requirement to 
state that email must be one of the problem reporting methods supported.

Another argument in favor or requiring CAs to accept problem reports via email 
is that it provides the reporter with evidence of the submission via their 
email client and server logs.

Arguments against this requirement include the burden placed on CAs who must 
sort through the large quantities of SPAM received by any published email 
address, concerns with email reliability, and the reporter's inability to 
confirm that their email has been received by the CA.

According to CCADB [1], all but a handful of CAs already support problem 
reporting via email.

I would appreciate everyone's input on this topic.

This is: https://github.com/mozilla/pkipolicy/issues/98

[1]
https://ccadb-public.secure.force.com/mozilla/ProblemReportingMechanismsReport
---

This is a proposed update to Mozilla's root store policy for version 2.6. 
Please keep discussion in this group rather than on GitHub. Silence is consent.

Policy 2.5 (current version):
https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
___
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: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

[Jeremy Rowley via dev-security-policy]

If you don't specify by EKU, the exercise of determining intent becomes
impossible as illustrated by our (many) attempts to define a server cert in
CAB Forum. Better to list the EKUs allowed and not allowed in the same cert
than rely on another intent requirement. 

-Original Message-
From: dev-security-policy

On Behalf Of Doug Beattie via dev-security-policy
Sent: Tuesday, April 17, 2018 1:37 PM
To: Wayne Thayer ; mozilla-dev-security-policy

Subject: RE: Policy 2.6 Proposal: Require separate intermediates for
different usages (e.g. server auth, S/MIME)



> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of
> Wayne Thayer via dev-security-policy
> Sent: Tuesday, April 17, 2018 2:24 PM
> To: mozilla-dev-security-policy  pol...@lists.mozilla.org>
> Subject: Policy 2.6 Proposal: Require separate intermediates for 
> different usages (e.g. server auth, S/MIME)
> 
> This proposal is to require intermediate certificates to be dedicated 
> to specific purposes by EKU. Beginning at some future date, all newly 
> created intermediate certificates containing either the 
> id-kp-serverAuth or id-kp- emailProtection EKUs would be required to
contain only a single EKU.

We'll need to support a list of EKUs if this becomes a requirement.  Server
Auth certificates should be able to support lots of different EKUs, for
example: 
id-kp-serverAuth
id-kp-clientAuth
id-kp-ipsecEndSystem
id-kp-ipsecTunnel
id-kp-ipsecUser
KDC Authentication
Smart Card Logon
iPSec IKE
IKE Intermediate

> Arguments for this requirement are that it reduces risk of an incident 
> in which one type of certificate affecting another type, and it could 
> allow some policies to be restricted to specific types of certificates.
> 
> It was pointed out that Microsoft already requires dedicated 
> intermediates [1].

I agree with using dedicated intermediates, but I'd prefer that they should
not be required to be EKU constrained.

> I would appreciate everyone's input on this topic.
> 
> I suspect that it will be tempting to extend this discussion into 
> intermediate rollover policies, but I would remind everyone of the 
> prior inconclusive discussion on that topic [2].
> 
> This is: https://github.com/mozilla/pkipolicy/issues/26
> 
> [1] https://aka.ms/rootcert
> [2]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/3NdNMiM-
> TQ8/hgVsCofcAgAJ
> ---
> 
> This is a proposed update to Mozilla's root store policy for version 2.6.
> Please keep discussion in this group rather than on GitHub. Silence is
consent.
> 
> Policy 2.5 (current version):
> https://github.com/mozilla/pkipolicy/blob/2.5/rootstore/policy.md
> ___
> 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

RAs and the BRs

[Jeremy Rowley via dev-security-policy]

There is a way to get zero-validation certs, totally legit, under the BRs.
Currently, the BRs permit pretty much free delegation of Registration
Authorities for everything except domain verification. Without RA audit
requirements or even a requirement that the CA monitor/control the RA, the
cynical-side of me doubts whether the verification is enforced without the
CA first receiving a third-party complaint. Section 1.32 permits free RA
delegation if the verification requirements are met by the process as a
whole and that a contract exist between the delegated third party to do the
following:"(1) Meet the qualification requirements of Section 5.3.1, when
applicable to the delegated function; (2) Retain documentation in accordance
with Section 5.5.2; (3) Abide by the other provisions of these Requirements
that are applicable to the delegated function; and (4) Comply with (a) the
CA's Certificate Policy/Certification Practice Statement or (b) the
Delegated Third Party's practice statement that the CA has verified complies
with these Requirements.". Essentially, as long as there is a) a contract
between the CA and RA, and b) the CA is performing domain verification (and
c) no one complains), the RA is free to do whatever the RA deems
appropriate, permitting the CA to circumvent the BRs and audit oversight.
There's no requirement that the CA audit the RA's role in the verification
process or that the RA provide any reporting to the CA or auditors. 

 

Combined with method 1, there is no obligation the CA actually do anything
to vet the customer or obtain any evidence that the customer even exists.
As you all know, method 1 requires only that the CA confirm the WHOIS
information matches the applicant. As long as the WHOIS information matches,
problem solved. As noted above, the RA is not actually required to do any
validation (just say that they do) so if the RA passes over the WHOIS name
as the verified information, the cert will issue without a second glance.  

 

I realize that method 1 and method 5 are going away (for good reason), but
that doesn't happen until August. I'd be interested in seeing whether
someone can get a cert in this manner from a CA that supports RAs. 

 

Jeremy 



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: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Jeremy Rowley via dev-security-policy]

True. I can tell you our process was not followed in this case, primarily 
because of the Symantec transaction.



Ideally, when we add new products (or when a CAB Forum requirement changes), 
we:

1.  Add the mandatory criteria to our compliance engine
2.  Add the new cert to our issuing CA
3.  Add the validation requirements in validation service
4.  Train the staff on the new product/service
5.  Enable access via the API and GUI



For the most part compliance takes place in two areas (in our updated system). 
First in the compliance engine for all things technical. Second in the 
validation service for all validation requirements. On the onion cert issue, 
we only did #2 and #4.



From: dev-security-policy 
 On 
Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, March 22, 2018 9:31 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert .onion certificates without Tor Service Descriptor Hash 
extension



On 21 Mar 2018 17:58, Wayne Thayer via dev-security-policy 
 > wrote:

7.  List of steps your CA is taking to resolve the situation and
ensure such issuance will not be repeated in the future, accompanied
with a timeline of when your CA expects to accomplish these things.

We revoked the certificates and added preliminary checking for Tor
descriptors. We are adding additional checks to ensure certs cannot
issue without them.



A broader consideration might be how DigiCert (or any CA) can ensure such 
checks get thought up / planned for during the process of spinning up a new 
type of issuance.

Imagine the CA/B eventually authorizes some hypothetical new "MV" 
certificates, they are Web PKI certs but with some different (less / more / 
just strange) validation and criteria for the cert itself. Obviously we cannot 
plan today for how this should be done exactly, but a CA thinking of issuing 
MV ought to - as part of that - figure out what needs to happen in terms of 
preventing mis-issuance of the new certs.

Otherwise we're inevitably back here shortly after the CA/B says OK.



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: DigiCert .onion certificates without Tor Service Descriptor Hash extension

[Jeremy Rowley via dev-security-policy]

Interesting - this escaped our notice because it has a Tor descriptor. 
Unfortunately, it looks like the fetch function with v3 is not supported so 
we'll have to change how we pull and include the descriptor. Since the key is 
already in the cert, I agree there is nothing gain by including it, but I 
doubt there's strong incentives to change the guidelines right now. We'll 
modify to include it.

-Original Message-
From: Alex Cohn <a...@alexcohn.com>
Sent: Monday, March 12, 2018 6:55 PM
To: Jeremy Rowley <jeremy.row...@digicert.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert .onion certificates without Tor Service Descriptor Hash 
extension

Thanks, Jeremy.

I also found a certificate [1] with both 16-character.onion and 
56-character.onion addresses [2] listed in the SAN. The v3 address is not 
included in the 2.23.140.1.31 extension, which seems to violate the same rule 
as below. However, v3 addresses include the service's entire public key in the 
address itself, so there's nothing to be gained by embedding a hash of that 
key in a certificate.

I'm not sure what, if anything, needs to happen in this case. Thoughts?

Alex

[1] https://crt.sh/?id=351449246
[2] https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt

On Mon, Mar 12, 2018 at 7:28 PM, Jeremy Rowley via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
> Thanks Alex. Sorry for the delayed response. I've been traveling today.
> We're reaching out to each of the customers and getting their cert replaced.
>
>
> Looking into this, we did not correctly implement the ballot:
> 1. We didn't add a check to our backend system too verify the cert
> included a descriptor prior to issuance.
> 2. On the front end, we missed requiring a Tor descriptor prior to
> processing the order.
> 3. The validation team received insufficient training on the Tor
> descriptor requirement.
>
> In reality, the issue was too much reliance on the human component of
> asserting the Tor descriptors instead of having a technical control in
> place. We're working on putting those technical controls in place.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy
> <dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla.
> org> On Behalf Of Alex Cohn via dev-security-policy
> Sent: Sunday, March 11, 2018 9:37 PM
> To: dev-security-policy@lists.mozilla.org
> Subject: DigiCert .onion certificates without Tor Service Descriptor
> Hash extension
>
> In the EV Guidelines [1], Appendix F states "The CA MUST include the
> CAB Forum Tor Service Descriptor Hash extension in the TBSCertificate
> convey hashes of keys related to .onion addresses." This language was
> added in Ballot 201 [2], which had an effective date of 8 July 2017.
>
> The following certificates (and precertificates if the corresponding
> certificate is not in a public CT log) were issued by DigiCert after 8
> July for .onion domains, but lack the necessary extension:
> https://crt.sh/?q=240277340 (revoked 26 October 2017)
> https://crt.sh/?q=261570255
> https://crt.sh/?q=261570338
> https://crt.sh/?q=261570380
> https://crt.sh/?q=261570384
> https://crt.sh/?q=261579788
> https://crt.sh/?q=261601212
> https://crt.sh/?q=261601280
> https://crt.sh/?q=261601281
> https://crt.sh/?q=261601284
> https://crt.sh/?q=261988060
> https://crt.sh/?q=326491168
> https://crt.sh/?q=326830043
> https://crt.sh/?q=328308725
> https://crt.sh/?q=328961187
> https://crt.sh/?q=329559222
> https://crt.sh/?q=330180704
> https://crt.sh/?q=351449233 (revoked 10 March 2018 after initial email
> to
> DigiCert)
>
> This was previously discussed on m.d.s.p about a year ago [3].
>
> [1]
> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-EV-Guidelines-v1.6.
> 8.pdf
> [2] https://cabforum.org/2017/06/08/2427/
> [3]
> https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNt
> s/ZtNI
> D_xfAgAJ
> ___
> 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

How do you handle mass revocation requests?

[Jeremy Rowley via dev-security-policy]

Hi everyone,

 

I wanted to share an incident report regarding the revocation of certain
certificates ordered through a reseller.

 

On February 2nd, 2018, we received a request from Trustico to mass revoke
all certificates that had been ordered by end users through Trustico.
Unfortunately, the email was not sent to the appropriate certificate problem
reporting channels and did not surface immediately so we're delayed in
sharing the concerns and information. Once we were alerted, the team kicked
off a debate that I wanted to bring to the CAB Forum. Basically, our
position is that resellers do not constitute subscribers under the Baseline
Requirement's definitions (Section 1.6.1). As such, we needed to confirm
that either the key was compromised or that they revocation was authorized
by the domain holder (the subscriber) prior to revoking the certificate. The
certificates were not alleged as compromised at that time.  

 

Later, the company shared with us that they held the private keys and the
certificates were compromised, trying to trigger the BR's 24-hour revocation
requirement.  However, we insisted that the subscriber must confirm the
revocation request or there must be evidence of the private key compromise. 

 

Normally, we permit partners to revoke and manage the certificates freely on
behalf of their customer, with DigiCert providing all validation and
issuance services. However, the sheer number of revocation requests (50k)
and allegation of compromise triggered concerns around the impact to the web
and browser users. Therefore, this was categorized as high risk, especially
considering the relationship between Trustico and DigiCert is terminating.

 

On 2/27/2018, at my request for proof of compromise, we received a file with
23k private keys matched to specific Trustico customers. This definitely
triggered our 24-hour revocation processing requirement under 4.9.1.1.3.
Once we received the keys, we confirmed that these were indeed the matching
private keys for the reported certificates. We will be revoking these
certificates today (February 28th, 2018).

 

At this time, Trustico has not provided any information about how these
certificates were compromised or how they acquired the private keys. As is
standard practice for a Certificate Authority, DigiCert never had possession
of these private keys.

 

Currently, we are only revoking the certificates if we received the private
keys. There are additional certificates the reseller requested to have
revoked, but DigiCert has decided to disregard that request until we receive
proof of compromise or more information about the cause of this incident.

 

DigiCert sent out emails to the affected customers in order to notify them
that their certificate(s) are being revoked. This revocation only affects
those customers and there is no additional exposure that we are aware of at
this time, nor any reason to believe there is.  

 

This raises a question about the MDSP policy and CAB Forum requirements. Who
is the subscriber in the reseller relation?  We believe this to be the key
holder. However, the language is unclear. I think we followed the letter and
spirit of the BRs here, but I'd like feedback, perhaps leading to a ballot
that clarifies the subscriber in a reseller relationship.

 

This also brings up a ballot about the level of due diligence required for
cert revocation. We generally believe that the private key or demonstration
of domain control is sufficient to request revocation. Others are at the CAs
discretion. Should we clarify what the due diligence looks like? Are there
other things we should have done or been doing? 

 

What kind of transparency would the Mozilla community like around this
issue? There aren't many more facts than I shared above, but there is a lot
of speculation. Let me know what I can share to help alleviate confusion and
answer questions.

 

Jeremy

 

 



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: Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

Oh – I totally agree with you on the Google inclusion issue. Google meets the 
requirements for inclusion in Mozilla’s root policy so there’s no reason to 
exclude them. They have an audited CPS, support a community broader with certs 
than just Google, and have operated a CA without problems in the past. The 
discussion on Mozilla’s independence is important IMO where a) a Mozilla 
competitor as a module peer and b) having that same person also belong to a CA. 
There are legit concerns. Has any other CA served as a module owner? If not, 
why? I know Tim Hollebeek would be interested in being a peer. If he’s not 
permitted to be a peer, why not?

 

To be fair, separating out Ryan as a Google browser representative and Ryan as 
a module peer is…hard. Perhaps, he specifically is seen as more influential 
(from my point of view) than others simply because of his dual role.  

 

As I said before, Ryan’s a good module peer so I don’t disagree with your 
conclusion or any decision to keep him in that spot. But I think openness 
should include respectful conversation on the impact of influences, perceived 
or real, on the Mozilla direction.  What might help alleviate concerns is to 
describe how you (as a module owner) are going to ensure that if Ryan is 
reviewing and approving code or CA policies, they won’t be unfairly biased 
towards google or against its competitors? Maybe that’s a bad question, but I’m 
spit-balling on how we can move past speculation to address concerns raised.

 

From: Wayne Thayer  
Sent: Wednesday, September 26, 2018 3:39 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: Google Trust Services Root Inclusion Request

 

I'm disputing the conclusion that is being drawn from Jake's concerns, rather 
than the concerns themselves. Primarily, I disagree with the conclusion that 
because Google owns a browser with dominant market share and - due to the 
substantial contributions they make here - because Google has considerable 
influence in this community, they should not be allowed to participate in our 
root program as a CA. Secondarily, I disagree that a Google employee should not 
be a peer of this module due to the potential for a conflict of interest.

 

Unpacking this conclusion in terms of policy it implies, I think the argument 
being made is that any root store operator should be excluded from membership 
in the Mozilla program as a CA, and any employee of a CA should be prohibited 
from being a module peer. The argument is that this will protect us from future 
conflicts of interest (there seems to be agreement that the concern is 
hypothetical at this point).

 

My conclusion is that rather than creating somewhat arbitrary, exclusionary 
rules, we can and should instead rely on the openness and inclusiveness of our 
process to protect us from conflicts of interest. If Google attempts to gain 
preferential treatment for their CA from Mozilla, our community can and will 
identify it, reject it, and hold Mozilla accountable for acting in their best 
interest.

 

On Wed, Sep 26, 2018 at 9:49 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> >
wrote:

> I also should also emphasize that I’m speaking as Jeremy Rowley, not as
> DigiCert.
>
>
>
> Note that I didn’t say Google controlled the policy. However, as a module
> peer, Google does have significant influence over the policy and what CAs
> are trusted by Mozilla. Although everyone can participate in Mozilla
> discussions publicly, it’s a fallacy to state that a general participant
> has similar sway or authority to a module peer. That’s the whole point of
> having a separate class for peers compared to us general public.  With
> Google acting as a CA and module peer, you now have one CA heavily
> influencing who its competitors are, how its competitors operate, and what
> its competitors can do.  Although I personally find that you never misuse
> your power as a module peer, I can see how Jake has concerns that Google
> (as a CA) has very heavy influence over the platform that has historically
> been the CA watchdog (Mozilla).
>

Jeremy, I think this again deserves calling out, because this is
misrepresenting what module peership does, as well as the CA relationship.

I linked you to the definition of Module Ownership, which highlights and
emphasizes that the module peer is simply a recognized helper. To the
extent there is any influence, it is through the public discussions here.
If your concern is that the title confers some special advantage, that's to
misread what module peer is. If your concern is that the participation -
which provides solid technical arguments as well as the policy alternatives
- is influential, then what you're arguing against is public participation.

You're presenting these as factual, and that's misleading, so I'd like to
highlight what is 

RE: Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

Maybe Jake’s opinion is not being discarded as readily as I supposed. However, 
Jake’s last message left me disturbed that he didn’t feel listened to. 
Apologies if I’m overblowing the issue, which are definitely hypothetical at 
this point. I did want Jake to feel like his input is an important part of this 
discussion board. Not saying anyone made him feel otherwise intentionally of 
course, but his last message seemed frustrated.

 

From: Ryan Sleevi  
Sent: Wednesday, September 26, 2018 10:49 AM
To: Jeremy Rowley 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 

Subject: Re: Google Trust Services Root Inclusion Request

 

 

On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote:

I also should also emphasize that I’m speaking as Jeremy Rowley, not as 
DigiCert.

 

Note that I didn’t say Google controlled the policy. However, as a module peer, 
Google does have significant influence over the policy and what CAs are trusted 
by Mozilla. Although everyone can participate in Mozilla discussions publicly, 
it’s a fallacy to state that a general participant has similar sway or 
authority to a module peer. That’s the whole point of having a separate class 
for peers compared to us general public.  With Google acting as a CA and module 
peer, you now have one CA heavily influencing who its competitors are, how its 
competitors operate, and what its competitors can do.  Although I personally 
find that you never misuse your power as a module peer, I can see how Jake has 
concerns that Google (as a CA) has very heavy influence over the platform that 
has historically been the CA watchdog (Mozilla).

 

Jeremy, I think this again deserves calling out, because this is 
misrepresenting what module peership does, as well as the CA relationship.

 

I linked you to the definition of Module Ownership, which highlights and 
emphasizes that the module peer is simply a recognized helper. To the extent 
there is any influence, it is through the public discussions here. If your 
concern is that the title confers some special advantage, that's to misread 
what module peer is. If your concern is that the participation - which provides 
solid technical arguments as well as the policy alternatives - is influential, 
then what you're arguing against is public participation.

 

You're presenting these as factual, and that's misleading, so I'd like to 
highlight what is actually entailed.

  

The circumstances are different between the scenarios you describe with respect 
to the other browsers, as is market share.  If Microsoft wants to change CAs 
(and they already use multiple), they can without impacting public perception. 
If Apple wants to use another CA, they can without people commenting how odd it 
is that Apple doesn’t use the Apple CA. With Google controlling the CA and the 
Google browser, all incentive to eliminate any misbehaving Google CA disappears 
for financial reasons, public perception, and because Google can control the 
messaging (through marketshare and influence over Mozilla policy). Note that 
there is historical precedent for Google treating Google special – i.e. the 
exclusion for Google in the Symantec distrust plan.  Thus, I think Jake’s 
concerns should not be discarded so readily.

 

I can understand and appreciate why you have this perspective. I disagree that 
it's an accurate representation, and as shown by the previous message, it does 
not have factual basis. I think it's misleading to suggest that the concerns 
are being discarded, much like yours - they're being responded to with 
supporting evidence and careful analysis. However, they do not hold water, and 
while it would be ideal to convince you of this as well, it's equally important 
to be transparent about it.

 

Your argument above seems to boil down to "People would notice if Google 
changed CAs, but not if Microsoft" - yet that's not supported (see, example, 
the usage of Let's Encrypt by Google, or the former usage of WoSign by 
Microsoft). Your argument about incentives entirely ignores the incentives I 
just described to you previously - which look at public perception, internet 
security, and ecosystem stability. Your argument about influence over Mozilla 
policy has already been demonstrated as false and misleading, but it seems you 
won't be convinced by that. And your suggestion of special treatment ignores 
the facts of the situation (the validation issues, the scoping of audits, that 
Apple and 2 other CAs were also included in the exclusion), ignores the more 
significant special treatment granted by other vendors (e.g. Apple's exclusion 
of a host of mismanaged Symantec sub-CAs now under DigiCert's operational 
control), the past precedent (e.g. the gradual distrust of WoSign/StartCom 
through whitelists, of CNNIC through whitelists), and the public discussion 
involved so entirely that it's entirely unfounded.

 

So I think your continued suggestion that it's being discarded so 

DigiCert incident report

[Jeremy Rowley via dev-security-policy]

Hi all, 
 
We issued a single certificate that contained an internal domain. This
certificate was discovered on Oct 16th and revoked on the 17th. We filed the
bug report here: https://bugzilla.mozilla.org/show_bug.cgi?id=1500621 but
are also posting the list for awareness. 
 
Tl;dr. Two validation agents overrode our compliance checks and authorized
issuance of a certificate, completing the domain validation using an
unauthorized email. We're moving from cablint to zlint as our pre-issuance
compliance check and removing the ability of validation agents to override
the compliance check.  
 
Thanks,
Jeremy
 
 
Bug report:
 
1.   How your CA first became aware of the problem (e.g. via a problem
report submitted to your Problem Reporting Mechanism, a discussion in
mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and
the time and date.
 
On 10/16/2018, we were notified by a third party that they had identified an
internal name on a publicly issued certificate, unrelated to their business,
within the past week.
 
2.   A timeline of the actions your CA took in response. A timeline is a
date-and-time-stamped sequence of all relevant events. This may include
events before the incident was reported, such as when a particular
requirement became applicable, or a document changed, or a bug was
introduced, or an audit was done.
 
10/16/18 A certificate with an internal domain name was reported to us by a
third party
 
10/16/18 We investigated the root cause including the source of the request
and the system that issued the problem certificate. We identified a gap in
our domain pre-validation process that allowed a certificate containing an
internal name to be submitted for validation by a customer. This was
intentional as certificates for use cases other than the WebPKI use the same
validation engine. Once an internal name was queued for validation, a
validation agent overrode the base domain's classification as "private" and
manually performed a WHOIS procedure which is only allowed when automatic
WHOIS data retrieval used to determine the email address for a method 2
email-based domain validation fails. The WHOIS lookup procedure allowed a
validation agent to send a domain confirmation email to the customer
containing a base domain substring of the FQDN, and the customer proceeded
to approve the internal name in response to the method 2 confirmation.
Because the automated WHOIS data retrieval failed in this case, it exposed
an unintended ability for the validation agent to perform an override,
categorize the domain as authorized for the WebPKI, and incorrectly approve
the certificate. 
 
10/17/18 We revoked the one problem certificate and moved the pre-issuance
check behind the validation process, ensuring the system blocks internal
names for public certs regardless of validation staff mistakes. We also
implemented changes on our portals to prevent the gap that allowed internal
names into our domain pre-validation process for WebPKI. We have also
improved our linting process pre-issuance to catch similar situations.
 
10/17/18 We ran a script over our existing certificate database to identify
certs affected by this issue. No additional certificates were identified.
 
3.Whether your CA has stopped, or has not yet stopped, issuing
certificates with the problem. A statement that you have will be considered
a pledge to the community; a statement that you have not requires an
explanation.
 
On 10/17/18, we implemented two fixes and a linting enhancement to prevent
this problem from re-occurring.  The linting enhancement checks the
certificate pre-issuance but post validation to ensure no additional issues
exist.
 
 
4.A summary of the problematic certificates. For each problem: number of
certs, and the date the first and last certs with that problem were issued. 
 
 Impact of one certificate, issued on 10/10/2018.
 
 
7.The complete certificate data for the problematic certificates. 
 
   https://crt.sh/?id=845405886
 
6.   Explanation about how and why the mistakes were made or bugs
introduced, and how they avoided detection until now.
 
Limited front-end PSL checking allowed an internal domain name request to be
submitted to our validation queue for human review. Although this is
intentional because we support non-WebPKI systems, there was an override in
the validation process that allowed a validation agent to approve the
certificate for WebPKI. The override was added to allow a validation agent
to override a pre-issuance check when manually accessing WHOIS data and
providing the method 2 Domain Contact email address to the system. The
override feature was only available if the automated WHOIS Domain Contact
email address lookup service failed for the submitted domain. The override
also allowed the validation staff to incorrectly approve non-WebPKI
certificates for WebPKI once validation completed. A combination of these
two problems permitted a 

RE: Google Trust Services Root Inclusion Request

[Jeremy Rowley via dev-security-policy]

I also should also emphasize that I’m speaking as Jeremy Rowley, not as 
DigiCert.

 

Note that I didn’t say Google controlled the policy. However, as a module peer, 
Google does have significant influence over the policy and what CAs are trusted 
by Mozilla. Although everyone can participate in Mozilla discussions publicly, 
it’s a fallacy to state that a general participant has similar sway or 
authority to a module peer. That’s the whole point of having a separate class 
for peers compared to us general public.  With Google acting as a CA and module 
peer, you now have one CA heavily influencing who its competitors are, how its 
competitors operate, and what its competitors can do.  Although I personally 
find that you never misuse your power as a module peer, I can see how Jake has 
concerns that Google (as a CA) has very heavy influence over the platform that 
has historically been the CA watchdog (Mozilla). 

 

The circumstances are different between the scenarios you describe with respect 
to the other browsers, as is market share.  If Microsoft wants to change CAs 
(and they already use multiple), they can without impacting public perception. 
If Apple wants to use another CA, they can without people commenting how odd it 
is that Apple doesn’t use the Apple CA. With Google controlling the CA and the 
Google browser, all incentive to eliminate any misbehaving Google CA disappears 
for financial reasons, public perception, and because Google can control the 
messaging (through marketshare and influence over Mozilla policy). Note that 
there is historical precedent for Google treating Google special – i.e. the 
exclusion for Google in the Symantec distrust plan.  Thus, I think Jake’s 
concerns should not be discarded so readily. 

 

 

 

From: Ryan Sleevi  
Sent: Wednesday, September 26, 2018 12:43 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services Root Inclusion Request

 

(While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm going 
to emphasize that this response is in a personal capacity)



On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Jake's concern is legit if you believe certain assumptions. Criticizing his
rationale doesn't seem correct, especially since Google does indeed have a
root store. Although not traditional, Google runs a store of blacklisted CAs
(see Symantec), which is every bit as effective as controlling CA compliance
and operation as the inclusion process.

 

To be clear: Google does indeed operate root stores on a host of devices, 
including Android and ChromeOS, not to mention Google Cloud functionality.

 

FACT: As a browser, Google already interprets the CA/Browser requirements in
many ways via, intentionally or not.  The Google's policies, and how Google
implements Chrome are all closely watched by CAs and help dictate how we
interpret the various requirements.  

 

This fact combined with the assumption that Google will never distrust
itself jumps to a conclusion that Google will only interpreting the BRs in
Google CA's best interests. Why wouldn't they? Google is a for profit
company. Self-promotion is kind-of in the description.

 

The problem with this assumption, or at least what logically follows, is that 
every Browser would behave the same, beneficient towards the CA(s) they use for 
services. For example, Microsoft operates a root program, yet is also trusted 
by Mozilla through the subordinate CAs provided through the Baltimore 
Cybertrust hierarchy, which is owned by... DigiCert. Similarly, Apple operates 
a root program, yet is also trusted by Mozilla through subordinate CAs provided 
through the GeoTrust hierarchy, which is owned by... DigiCert.

 

Google operates a root program, yet is also trusted by Mozilla through... the 
acquisition of key material (from GlobalSign) and the operation of independent 
roots.

 

If we accept this assumption as sound, then it seems the argument is that 
DigiCert can also never be distrusted, and interpretations will always be to 
the benefit of DigiCert, because to distrust DigiCert or take sanction would be 
to disrupt 'critical' services like Azure or iTunes.

 

Alternatively, one could argue/make assumptions that by virtue of Google 
previously having operated a subordinate under the GeoTrust hierarchy 
(DigiCert, formerly Symantec), that they've demonstrated it's possible to 
operate as subordinate or root. They demonstrably took steps regarding the 
Symantec hierarchy, even as it was the basis for trust of Google services. In 
that model, if Google CA were to take actions detrimental to the ecosystem, 
Google may interpret the BRs in the Internet trust and stabilities best 
interests, distrust the Google CA, and force Google to transition to an 
alternative solution precisely to avoid the alternative.

 

The problem here is these are all assum

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

>> I think Matt provided a pretty clear moral hazard here - of customers 
>> suggesting their CAs didn't do enough (e.g. should have tried harder to 
>> intentionally violated by not revoking). One significant way to mitigating 
>> that risk is to take meaningful steps to ensure that "We couldn't revoke" is 
>> not really a viable or defensible option.

 

Oh – thanks. I missed that. A lack of knowledge is already not a defensible 
position. Revocation requirements and an agreement to revoke within 24 hours is 
in all our of existing DigiCert contracts. The same language is going into all 
Symantec customer contracts now as customers transition to DigiCert systems. 
All of our documentation, including the CPS, say we can revoke with less than 1 
day notice. 

 

>From section 4.9.1 of our CPS:

 

DigiCert will revoke a Certificate within 24 hours if one or more of the 
following occurs: 

1.  The Subscriber requests in writing that DigiCert revoke the 
Certificate; 
2.  The Subscriber notifies DigiCert that the original Certificate request 
was not authorized and does not retroactively grant authorization; 

3.DigiCert obtains evidence that the Subscriber’s Private Key corresponding to 
the Public Key in the Certificate suffered aKey Compromise; or 

4. DigiCert obtains evidence that the validation of domain authorization or 
control for any FDQN or IP address in the Certificate should not be relied 
upon. 

 

DigiCert may revoke a certificate within 24 hours and will revoke a Certificate 
within 5 days if one or more of  the following occurs: 

1.  The Certificate no longer complies with the requirements of Sections 
6.1.5 and 6.1.6 of the CA/B forum baseline requirements; 
2.  DigiCert obtains evidence that the Certificate was misused; 

 3.The Subscriber or the cross‐certified CA breached a material obligation 
under the CP, this CPS, or the relevant agreement; 

4. DigiCert confirms any circumstance indicating that use of a FQDN or IP 
address in the Certificate is no longer legally permitted (e.g. a court or 
arbitrator has revoked a Domain Name registrant’s right to use the Domain Name, 
a relevant licensing or services agreement between the Domain Name registrant 
and the Applicant has terminated, or the Domain Name registrant has failed to 
renew the Domain Name); 

5. DigiCert confirms that a Wildcard Certificate has been used to authenticate 
a fraudulently misleading subordinate FQDN; 

6. DigiCert confirms a material change in the information contained in the 
Certificate; 

7. DigiCert confirms that the Certificate was not issued in accordance with the 
CA/B forum requirements or the DigiCert CP or this CPS; 

8. DigiCert determines or confirms that any of the information appearing in the 
Certificate is inaccurate; 

9. DigiCert’s right to issue Certificates under the CA/B forum requirements 
expires or is revoked or terminated, unless DigiCert has made arrangements to 
continue maintaining the CRL/OCSP  Repository; 

….

 

This is why I couch it as we can revoke technically and legally, but I don’t 
think we should. 

 

>> This doesn't really inspire confidence. If the answer for how to deal with 
>> this is block efforts to remediate issues, then it runs all the risk that 
>> Matt was speaking to. "We knew people couldn't replace in January" is a 
>> problem, for sure, but because fundamentally the risk is always there that 
>> someone would need to revoke in January - or December, or November, or 
>> whenever the sensitive holiday freeze or critical sales or lunar alignment 
>> or personal vacation is - it's not really a mitigation at all for the issue.

 

>> I tried to give suggestions earlier for meaningful steps - such as making 
>> sure all customers know that certificates may need to be revoked as soon as 
>> 24 hours. This has been a pattern of challenge in the past for DigiCert if I 
>> recall correctly - I believe both Blizzard and GitHub had issues where the 
>> keys were compromised, but these organizations didn't want to revoke the 
>> certs until they could ship new private keys in their software (... ignoring 
>> all the issues in that one). I know you've said you've got the contracts in 
>> place to defensibly revoke these, but how are you helping your users 
>> understand these risks? Do you have documentation on this? Do you recommend 
>> users use automation? I know some of this speaks to business practice, but I 
>> think that's somewhat core to the issue - since revocation may be required, 
>> how is the CA, the party best placed to communicate to the customer, 
>> communicating that necessity?

 

Sorry – I thought you meant in addition to those things. All customers know we 
can revoke within 24 hours. Note that in both those cases the GitHub case we 
did revoke the cert within 24 hours of notification. We have documentation on 
revocation (eg https://www.digicert.com/certificate-revocation.htm) and talk 
about it a lot. We also recommend 

RE: Use cases of publicly-trusted certificates

[Jeremy Rowley via dev-security-policy]

It clearly wasn't understood by everyone. That's why we had two ballots on it, 
one of them failing to address the issue. You can just look through the long 
discussions on the topic to see people didn't agree. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Jakob Bohm via dev-security-policy
Sent: Thursday, December 27, 2018 2:43 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Use cases of publicly-trusted certificates

On 27/12/2018 18:03, Nick Lamb wrote:
> On Thu, 27 Dec 2018 15:30:01 +0100
> Jakob Bohm via dev-security-policy
>  wrote:
> 
>> The problem here is that the prohibition lies in a complex legal 
>> reading of multiple documents, similar to a situation where a court 
>> rules that a set of laws has an (unexpected to many) legal 
>> consequence.
> 
> I completely disagree. This prohibition was an obvious fact, well 
> known to (I had assumed prior to this present fever) everyone who 
> cared about the Internet's underlying infrastructure.
> 

The group who most definitely were unaware of the very specific reading of 
RFC5280 is the subscribers using such host names in ways that passed all other 
requirements (including domain name validation).
Not the people seeking to allow these names via ballot 202, similar to what was 
done for other RFC5280 deviations in ballots 75, 88 and 144.

> The only species of technical people I ever ran into previously who 
> professed "ignorance" of the rule were the sort who see documents like 
> RFCs as descriptive rather than prescriptive and so their position 
> would be (as it seems yours is) "Whatever I can do is allowed". Hardly 
> a useful rule for the Web PKI.
> 

You must be traveling in a rather limited bubble of PKIX experts, all of whom 
live and breathe the reading of RFC5280.  Technical people outside that bubble 
may have easily misread the relevant paragraph in RFC5280 in various ways.

Possible ways to overlook the ban on underscores:

1. Not chasing down the RFC1034/RFC1123 references but relying on
  previously learned rules for what can be in a DNS name.

2. Interpreting the wording in RFC5280 section 4.2.1.6 as simply requiring
  a canonical encoding of DNS names, thus not allowing e.g. the UTF-8
  equivalent of an IDN or duplicate periods, then deferring that encoding
  job to a 3rd party PKI library.

3. Relying on practice established in certificates without the SAN extension,
  (thus not subject to section 4.2.1.6 rules) and then continuing without
  detailed review after it became mandatory to always include the SAN
  extension for end entities.

4. Trusting the word of others on how to interpret the rules, those others
  being the ones misreading the standards.

> Descriptive documents certainly have their place - I greatly admire 
> Geoff Pullum's Cambridge Grammar of the English Language, and I do own 
> the more compact "Student's Introduction" book, both of which are 
> descriptive since of course a natural language is not defined by such 
> documents and can only be described by them (and imperfectly, exactly 
> what's going on in English remains an active area of research).
> But that place is not here, the exact workings of DNS are prescribed, 
> in documents you've called a "complex legal reading of multiple documents"
> but more familiarly as "a bunch of pretty readable RFCs on exactly 
> this topic".
> 

The documents that prescribes the exact workings of DNS do not prohibit (only 
discourage) DNS names containing underscores.  Web browser interfaces for URL 
parsing may not allow them, which would be a technical benefit for at least one 
usage of such certificates reported in the recent discussion.

The complex reading comes in the understanding that a single sentence in
RFC5280 elevates the recommendation in the DNS standards to an absolute 
requirement in PKIX, combined with the opinion that this particular effect of 
the wording is not another errata that should be corrected in any later update 
of the PKIX standard, and/or overridden by a BR clause.

>> It would benefit the honesty of this discussion if the side that won 
>> in the CAB/F stops pretending that everybody else "should have known"
>> that their victory was the only legally possible outcome and should 
>> never have acted otherwise.
> 
> I would suggest it would more benefit the honesty of the discussion if 
> those who somehow convinced themselves of falsehood would accept this 
> was a serious flaw and resolve to do better in future, rather than 
> suppose that it was unavoidable and so we have to expect they'll keep 
> doing it.
> 
> Consider it from my position. In one case I know Jakob made an error 
> but has learned a valuable lesson from it and won't be caught the same 
> way twice. In the other case Jakob is unreliable on simple matters of 
> fact and I shouldn't believe anything further he says.
> 

That I disagree with you on certain questions of fact doesn't mean I'm 
unreliable, merely that you have not 

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

This is accurate. We have the technical capability and policy ability to
revoke the certificates. What we were hoping was a discussion based on
impact of the revocation so we could hear what we should do. Blind obedience
isn't my favorite answer, but it's an option. The guidance so far is file an
incident report now so we can discuss the potential impact. I've filed for
two companies, crossed a couple more off the list, and am still working with
the remainder to get things resolved. Although some have escalated over my
head, I think most are eager to hear what the community has to say. I also
think this is an interesting question for Mozilla's policy -  not sure we've
ever addressed a potential non-compliance like this.  

-Original Message-
From: dev-security-policy  On
Behalf Of Peter Bowen via dev-security-policy
Sent: Thursday, December 27, 2018 2:19 PM
To: thomas.gh.h...@gmail.com
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Underscore characters

On Thu, Dec 27, 2018 at 12:53 PM thomas.gh.horn--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> As to why these certificates have to be revoked, you should see this 
> the other way round: as a very generous service of the community to 
> you and your customers!
>
> Certificates with (pseudo-)hostnames in them are clearly invalid, so a 
> conforming implementation should not accept them for anything and they 
> should not pose any security risk. Based on this assessment (no 
> revokation if no security risk), a CA could very well issue a 
> certificate including any of the (psuedo-)hostnames 
> "example.com_cvs.com", "example.com/cvs.com", "cvs.com/example.com",
"https://example.com/cvs.com;, "example@cvs.com"
> to the owner of example.com (who, arguably, has the exact same right 
> to them as the owner of cvs.com has) and refuse to revoke them.
>

I'm not clear how you get that the owner of example.com is covered anywhere
here.  Parsed into labels, these all have com as the label closet to the
root and then have 'com_cvs', 'com/cvs', 'com/example', 'com/cvs', and
'com@cvs' as the next label respectively.  None have 'example' as the next
label.


> As to the consequences (in case this really becomes an incident 
> report/incident reports): this shows a SEVERE lack of ability to 
> revoke certificates on DigiCert's side, which must have been known AND 
> ACCEPTED for a long time (this cannot be the first "blackout period" 
> of (in the best
> case) 3.5 months).


I don't see how this follows.  DigiCert has made it clear they are able to
technically revoke these certificates and presumably are contractually able
to revoke them as well.  What is being said is that their customers are
asking them to delay revoking them because the _customers_ have blackout
periods where the customers do not want to make changes to their systems.
DigiCert's customers are saying that they are judging the risk from
revocation is greater than the risk from leaving them unrevoked and asking
DigiCert to not revoke. DigiCert is then presenting this request along to
Mozilla to get feedback from Mozilla.


> Thus, it seems to be a good idea to:
>
> 1. Henceforth, make NSS only accept certificates by DigiCert with a 
> maximum validity of 100 days. Let's Encrypt has shown that this is 
> clearly feasible.
>
> or
>
> 2. Henceforth, require DigiCert to revoke a small, randomly (e.g., 
> using RFC 3797) selected subset of their certificates every day (within 7
days).
> If this, e.g., for the same reasons as outlined in these incident 
> reports, is not possible, it will trigger (a incrementally decreasing 
> number of) more incident reports.
>
> Both proposals would lead to more automation and a better 
> understanding of the requirement of timely revocation, while pushing 
> the ecosystem in the right direction. For its easiness, the first 
> proposal would be my favorite but I would be very interested in 
> hearing other people's thoughts about these proposals.
>

I don't agree that demanding all certificate customers have "more
automation" is desirable.  I am very familiar with the Chaos Monkey approach
Netflix has implemented and companies like Gremlin that offer similar
"Failure as a Service" products, but forcing this on customers seems like a
poor idea.

Thanks,
Peter
___
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: Underscore characters

[Jeremy Rowley via dev-security-policy]

Treading carefully… 

 

Mozilla is the only browser related to the discussion. Probably sufficient to 
say that the revocation/no-revoke decision is entirely dependent on the results 
of this thread. 

 

From: James Burton  
Sent: Thursday, December 27, 2018 6:07 PM
To: Jeremy Rowley 
Cc: Matt Palmer ; mozilla-dev-security-policy 

Subject: Re: Underscore characters

 

I'm not sure if you're allowed to state this publicly. Has Microsoft giving you 
the go ahead?

 

On Fri, Dec 28, 2018 at 1:05 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

I disagree that we won't get that. I think we could see a "it's okay to wait
until April 30 for large pharmacy" or "Waiting until April 30 is too long
but March 1 is okay". I don't think Mozilla wants outages either. But... if
Mozilla did say that we should revoke now, that would be great as well. I'd
have a firm answer I can go back with. No risk, but no exception. 

Well except moral risk of course  

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On
Behalf Of Matt Palmer via dev-security-policy
Sent: Thursday, December 27, 2018 5:55 PM
To: dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
Subject: Re: Underscore characters

On Fri, Dec 28, 2018 at 12:12:03AM +, Jeremy Rowley via
dev-security-policy wrote:
> This is very helpful. If I had those two options, we'd just revoke all 
> the certs, screw outages. Unfortunately, the options are much broader than
that.
> If I could know what the risk v. benefit is, then you can make a 
> better decision? DigiCert distrusted - all revoked. DigiCert gets some 
> mar on its audit - outages seem worse. Make sense?

Given that Mozilla wants CAs to abide by its policies, which include
adherence to the BRs, and you appear to be saying that you'll adhere to the
BRs if you're threatened with distrust... I'd say the logical response from
Mozilla would be to threaten distrust.  I doubt, especially now, that you'll
get a categorical advance "it's OK to not revoke" from Mozilla.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://clicktime.symantec.com/a/1/JAUY6LMmpzDeGtxtOiXLJVWWYjWV65xcMjKoLj_GS 
<https://clicktime.symantec.com/a/1/JAUY6LMmpzDeGtxtOiXLJVWWYjWV65xcMjKoLj_GSgs=?d=2r4BCPONnLRAQaYxhIYsrR2xI_C73HdzeRvSzxfwF1rOccA0cfq95qcKptTpNVYkGzCfglu40QMyhwHQJyWghm9tDreLIrUFB4D0ugqZlnn2SKyEI85b9QcQlb6I-o78NypjSLQRAUF9s9i5tFsXc6oVsnhZly7GCR8HrTZqfLEL8fXQKwA8A7MRCYPr2Hy61TCorYztrVr2u8IME1WcJdVQxd1tkB>
 
gs=?d=2r4BCPONnLRAQaYxhIYsrR2xI_C73HdzeRvSzxfwF1rOccA0cfq95qcKptTpNVYkGzCfgl
u40QMyhwHQJyWghm9tDreLIrUFB4D0ugqZlnn2SKyEI85b9QcQlb6I-o78NypjSLQRAUF9s9i5tF
sXc6oVsnhZly7GCR8HrTZqfLEL8fXQKwA8A7MRCYPr2Hy61TCorYztrVr2u8IME1WcJdVQxd1tkB
MIgZG8M74du5AO2ELfvkGfV3pBYbOUubjwoFhmqqgsHy5GyDIO_EZS68OavUwfNHvpkZ-5paTSWR
yGwQFw0uz8CKa2kO0IOOBGt55A-WAyvJnhPJScUvwu_c9n2KmEljO7EbvvYGYA0E3Ef6rWWdpZbm
D8FZ39LChfaUgdEP4DX6Y%3D=https%3A%2F%2Flists.mozilla.org 
<http://2Flists.mozilla.org> %2Flistinfo%2Fdev-
security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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: Underscore characters

[Jeremy Rowley via dev-security-policy]

This is very helpful. If I had those two options, we'd just revoke all the
certs, screw outages. Unfortunately, the options are much broader than that.
If I could know what the risk v. benefit is, then you can make a better
decision? DigiCert distrusted - all revoked. DigiCert gets some mar on its
audit - outages seem worse. Make sense? 

-Original Message-
From: dev-security-policy  On
Behalf Of thomas.gh.horn--- via dev-security-policy
Sent: Thursday, December 27, 2018 1:50 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Underscore characters


As to why these certificates have to be revoked, you should see this the
other way round: as a very generous service of the community to you and your
customers!

Certificates with (pseudo-)hostnames in them are clearly invalid, so a
conforming implementation should not accept them for anything and they
should not pose any security risk. Based on this assessment (no revokation
if no security risk), a CA could very well issue a certificate including any
of the (psuedo-)hostnames "example.com_cvs.com", "example.com/cvs.com",
"cvs.com/example.com",
"https://clicktime.symantec.com/a/1/Bz3KjBhWfzAsIJ0uIM5iJZb_Vq9KOZqIbbEqrWx1
PPc=?d=nuBPRsMXvpmDCViEfj_vdMTuPr8sqLAI5iKEWF4ohV9p1yKSHaat1UnUMwQC2TM1Glbqm
sZ5vll_Ws-lffmZiGXLoAjAa1j4xYlIvj_mjSSwyyAqosT8up883sRCNtFds_0zcjRxOOoj2-Clo
cugotsEOb5kZj4DN2uJO-MXnpA-ayZPZSvrBhJ61IzJdnfMh1ufcgt0H6eS4MDVVELwAzREz5sDF
lQhRCO_bmD3I3jI7vj9qUbLzQFJGYVKa0aQ_RlnmWxfRFD0s4bJcUeW2SLinms3T2PnVDt62TguH
hnVQeT7XLb0uAGF0x7KNhbpJbykznPGT6vDGP6xnntYiQHZgZqRiOfJvYE642rqp3X9NoRx26Q0Q
Qy4KgOGUE-nAs60vFYry1msFrinKGViW9Q%3D=https%3A%2F%2Fexample.com%2Fcvs.com"
, "example@cvs.com" to the owner of example.com (who, arguably, has the
exact same right to them as the owner of cvs.com has) and refuse to revoke
them.

As to the consequences (in case this really becomes an incident
report/incident reports): this shows a SEVERE lack of ability to revoke
certificates on DigiCert's side, which must have been known AND ACCEPTED for
a long time (this cannot be the first "blackout period" of (in the best
case) 3.5 months). Thus, it seems to be a good idea to:

1. Henceforth, make NSS only accept certificates by DigiCert with a maximum
validity of 100 days. Let's Encrypt has shown that this is clearly feasible.

or

2. Henceforth, require DigiCert to revoke a small, randomly (e.g., using RFC
3797) selected subset of their certificates every day (within 7 days). If
this, e.g., for the same reasons as outlined in these incident reports, is
not possible, it will trigger (a incrementally decreasing number of) more
incident reports.

Both proposals would lead to more automation and a better understanding of
the requirement of timely revocation, while pushing the ecosystem in the
right direction. For its easiness, the first proposal would be my favorite
but I would be very interested in hearing other people's thoughts about
these proposals.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/2hiT00ldRBQieEaN_06CurvCo04Hq3RsaRxAAoyWN
IY=?d=nuBPRsMXvpmDCViEfj_vdMTuPr8sqLAI5iKEWF4ohV9p1yKSHaat1UnUMwQC2TM1Glbqms
Z5vll_Ws-lffmZiGXLoAjAa1j4xYlIvj_mjSSwyyAqosT8up883sRCNtFds_0zcjRxOOoj2-Cloc
ugotsEOb5kZj4DN2uJO-MXnpA-ayZPZSvrBhJ61IzJdnfMh1ufcgt0H6eS4MDVVELwAzREz5sDFl
QhRCO_bmD3I3jI7vj9qUbLzQFJGYVKa0aQ_RlnmWxfRFD0s4bJcUeW2SLinms3T2PnVDt62TguHh
nVQeT7XLb0uAGF0x7KNhbpJbykznPGT6vDGP6xnntYiQHZgZqRiOfJvYE642rqp3X9NoRx26Q0QQ
y4KgOGUE-nAs60vFYry1msFrinKGViW9Q%3D=https%3A%2F%2Flists.mozilla.org%2Flis
tinfo%2Fdev-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: Underscore characters

[Jeremy Rowley via dev-security-policy]

The 7 required items under the Mozilla template are:

1.  Timeline of events
2.  Timeline of actions taken
3.  Whether the CA has stopping issuing
4.  Summary of problematic certs
5.  Cert data
6.  How mistakes were made
7.  Remediation plan

 

The info we’re working on getting a complete list of:

1.  Blackout periods
2.  Where each cert is used in the infrastructure
3.  Why 30 day certs won’t work (on a per cert basis)
4.  Reason the certs are publicly trusted
5.  What risk are associated with the replacement
6.  The date each cert can be revoked

 

Mostly we’re hearing back general answers. They’re almost all the same answer, 
but I’m really trying to get the level of detail requested.

 

I see how you could interpret the question that way. I see it more as the CAB 
forum got the date wrong. Could Mozilla please extend this after weighing the 
risks of revoking vs. non-revoking? Maybe two sides of the same question.

 

The second deadline is coming from the impacted parties. That’s the request 
from them so I’m relaying it on. Everyone is willing to move, just a matter of 
timing. If there’s a better balance of risk vs. risk, then we’d be happy to 
hear that.

 

>> So the assumption here is that, in all of this discussion, DigiCert's done 
>> everything it can to understand the issue, the

>> timelines, remediation, etc, and has plans to address both each and every 
>> customer and the systemic issues that have

>>  emerged. If that's not the case, then how are we not in one of those two 
>> scenarios above? And if it is the case, isn't that

>> information readily available by now?

 

The information is readily available for the companies I posted in incident 
reports, particularly the first one. I think we’ve done everything reasonable 
to understand the issue. I haven’t, for example, chartered a flight to sit in 
their data center and examine their infrastructure. We do have daily calls with 
most of them on the issue.  Maybe the amount of information the company has 
provided should be the guiding light? 

 

 

From: Ryan Sleevi  
Sent: Thursday, December 27, 2018 1:16 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: Underscore characters

 

I'm not trying to throw you under the bus here, but I think it's helpful if you 
could highlight what new information you see being required, versus that which 
is already required.

 

I think, yes, you're right that it's not well received if you go violate the 
BRs and then, after the fact, say "Hey, yeah, we violated, but here's why", and 
finding out that the reasons are met with a lot of skepticism and the math 
being shaky, and you can see that from past incident reports it doesn't go over 
well.

 

But it's also not well received if it's before, and the statement is "Our 
customer thinks we should violate the BRs. What would happen if we did, and 
what information do you need from us?". That gets into the moral hazard that 
Matt spoke to, and is a huge burden on the community where the expectation is 
that the CA says "Sorry, we can't do that".

 

So the assumption here is that, in all of this discussion, DigiCert's done 
everything it can to understand the issue, the timelines, remediation, etc, and 
has plans to address both each and every customer and the systemic issues that 
have emerged. If that's not the case, then how are we not in one of those two 
scenarios above? And if it is the case, isn't that information readily 
available by now?

 

>From the discussions on the incident reports, I feel like that's been the 
>heart of the questions; which is trying to understand what the root cause is 
>and what the remediation plan is. The statement "We'll miss the first 
>deadline, but we'll hit the second", but without any details about how or why, 
>or the steps being taken to ensure no deadlines are missed in the future, 
>doesn't really inspire confidence, and is exactly the same kind of feedback 
>that would be given post-incident.

 

On Thu, Dec 27, 2018 at 1:50 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

There's a little bit of a "damned if you do, damned if you don't problem here". 
Wait until you have all the information? That's a paddlin'.  File before you 
have enough information? That's a paddlin'. I'd appreciate better guidance on 
what Mozilla expects from these incident reports timing-wise. 

-----Original Message-----
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Jeremy 
Rowley via dev-security-policy
Sent: Thursday, December 27, 2018 11:47 AM
To: r...@sleevi.com <mailto:r...@sleevi.com> 
Cc: dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
Subject: RE: Underscore characters

The o

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

The risk Matt identified is too nebulous of an issue to address, tbh. How do 
you address a moral issue?  The only way I can think of to address the moral 
issue is to say “we promise to be good”. But the weight that carries depends on 
how much you trust the actor. If you trust the actor, then the moral issue is 
addressed. If you don’t trust the actor, moral issue is not addressed. If you 
or Matt can identify a specific threat you’d like me to address about the moral 
issue, I’ll do my best to respond. 

 

*   What happens is that you ask why there is risk of outage to begin with 
and what can be done to improve going forward? Let’s assume you do revoke, and 
it causes an outage - is DigiCert taking steps to ensure no customer of theirs 
is ever faced with that risk? If so, what are those steps?

 

Yeah – there are several things we can do to improve going forward:

1.  Communicate better with the customers. The first mistake was waiting 
until we had good data to communicate with the customers. This delayed 
notification. This was unknown to me at the time, or we would have sent out 
communication prior to the ballot passing. That instruction has been passed 
along (no waiting on these critical issues) plus training.
2.  No more skipping CAB Forum meetings for me. This was easily a 
foreseeable issue because we knew people couldn’t replace in January. I think 
it’s been brought up a half dozen times in the forum at least. I’m not sure why 
we didn’t communicate this in Shanghai. But, the real problem is I didn’t have 
direct knowledge of what was going on. I probably need to be there in person 
each time so we can align the company correctly with that is going on.

 

I don’t think we can ever take steps to ensure that no customer is ever faced 
with the risk of revoked certs. I’m sure there will be other items that are 
adopted we don’t foresee.  That said, we do promote automation, short-lived 
certs (you can get anything from about 8 hours up through our system), and CT 
logging. I think the biggest surprise on this one was it applied to certs that 
are no longer trusted by Mozilla or Google. 

 

> This seems to suggest that perhaps other CAs have prepared their customers 
> for revocation. How does this surprise - that no other CA faces this - lead 
> to tangible changes in the business processes? How would this change, if 
> another CA did have the same issue? Surely you can see there are real and 
> fundamental issues that you’re uniquely qualified to help your customers 
> address in ways that we cannot. 

 

I suppose they did prepare better. Maybe other CAs are just smarter than me? I 
won’t leave that off the table.  I agree that we are uniquely positioned to 
help our customers remediate. Definitely anxious to do that (and are doing so). 

 

*   Have you analyzed CT, for example, to see why DigiCert is unique? 
Certainly, by sheer volume, it's heavily tilted towards the old Symantec 
infrastructure - and the customers that came over to DigiCert. With those sorts 
of details, how does this change how things were done, or how they will be done?

 

We do know most of the customers were legacy Symantec, but there are definitely 
some DigiCert customers in there. I think we still continue the same course. 
It’s only been a year from the transition, and we’ve migrated nearly everyone 
off the Symantec infrastructure. Next comes shutting down all the legacy 
Symantec systems. 

 

*   I’m not trying to pick on y’all - I think it is legitimately good that 
you provided concrete data. Even if you do revoke on Jan 15, this is still 
useful to understand the challenges, but only if this leads to meaningful 
changes. What might those look like?

I appreciate that. I think these are all fair questions, and I’m trying my best 
to answer them. I especially don’t feel picked on since we’re requesting the 
information/decision on what to do.

 

I don’t know how to answer the question of what changes to make because I was a 
bit blindsided by the decision to revoke the certs. Probably shouldn’t have 
been considering the conversation at the CAB Forum.  My number one priority 
right now is to shut down all of the legacy Symantec systems. Last year was 
mostly migration of issuance and trying to get the systems up to an expected 
caliber of performance. At the same time we’re introducing industry-standard 
(and above) automation of issuance and deployment systems that we hope will 
help people replace certificates faster. 

 

*   And this is the framing that I think is incredibly helpful. 
Understanding why customers can’t change, and what steps are being done to 
ensure they can, is hugely useful. Wayne’s question were to this point - as 
were mine towards understanding the problem from the other side, which are 
steps the CA is taking. As I've repeatedly highlighted from 
https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation , the goal is 
not punishment - but 

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

The risk is primarily outages of major sites across the web, including certs 
used in Google wallet. We’re thinking that is a less than desirable result, but 
we weren’t sure how the Mozilla community would feel/react.  We’re still 
considering revoking all of the certs on Jan 15th based on these discussions.  
I don’t think we’re asking for leniency (maybe we are if that’s a factor?), but 
I don’t know what happens if you’re faced with causing outages vs. compliance. 
I started the conversation because I feel like we should be good netizans and 
make people aware of what’s going on instead of just following policy.  I’m 
actually surprised at least one other CA that has issued a large number of 
underscore character certs hasn’t run into the same timing issues. 

 

Normally, we would just revoke the certs, but there are a significant number of 
certs in the Alexa top 100. We’ve told most customers, “No exception”. I also 
thought it’s better to get the information out there so we can all make 
rational decisions (DigiCert included) if as many facts are known as possible.  

 

We are working with the partners to get the certs revoked before the deadline. 
Most will. By January 15th, I hope there won’t be too many certs left. 
Unfortunately, by then it’s also too late to discuss what happens if the cert 
is not revoked. Ie – what are the benefits of revoking (strict compliance) vs 
revoking the larger impact certs as they are migrated (incident report).  
Unfortunately part 2, there’s no guidance on whether an incident report means 
total distrust v. something on your audit and a stern lecture. I’d happily 
suffer a lecture than take down a top site. Not so willing to gamble the whole 
company. This is why we wanted to have the discussion now, despite no violation 
so far. The response from the browsers is public  - that they cannot make that 
determination. Does that mean we have our answer? Revoke is the only acceptable 
response?   

 

From: James Burton  
Sent: Thursday, December 27, 2018 2:24 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: Underscore characters

 

 

 

On Thu, Dec 27, 2018 at 9:00 PM Ryan Sleevi mailto:r...@sleevi.com> > wrote:

I'm not really sure I understand this response at all. I'm hoping you can 
clarify.

 

On Thu, Dec 27, 2018 at 3:45 PM James Burton mailto:j...@0.me.uk> > wrote:

For a CA to intentionally state that they are going to violate the BR 
requirements means that that CA is under immense pressure to comply with 
demands or face retribution. 

 

I'm not sure I understand how this flows. Comply with whose demands? Face 
retribution from who, and why?

 

The CA must be under immense pressure to comply with demands from certain 
customers to determine that they don't have much of a choice but to 
intentionally violate the BR requirements and by telling community and root 
stores early they are hoping for leniency. The retribution by them customers 
could be legal which is outside of this forum but is but it's still relevant to 
them if that is the case. 

 

 

The severity inflicted on a CA by intentionally violating the BR requirements 
can be severe. Rolling a dice of chance. Why take the risk?

 

I'm not sure I understand the question at the end, and suspect there's a point 
to the question I'm missing.

 

The CA is rolling the dice of chance, they are intentionally risking everything 
by violating the BR requirements and they know that such action can face 
sanctions or distrust in the wrong case. The question I asked is why are they 
taking the risk which leads from the first statement.  

 

 

Presumably, a CA stating they're going to violate the BR requirements, knowing 
the risk to trust that it may pose, would have done everything possible to 
gather every piece of information so that they could assess the risk of 
violation is outweighed by whatever other risks (in this case, revocation). If 
that's the case, is it unreasonable to ask how the CA determined that - which 
is the root cause analysis question? And how to mitigate whatever other risk 
(in this case, revocation) poses going forward, so that violating the BRs isn't 
consistently seen as the "best" option? 



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: Underscore characters

[Jeremy Rowley via dev-security-policy]

I disagree that we won't get that. I think we could see a "it's okay to wait
until April 30 for large pharmacy" or "Waiting until April 30 is too long
but March 1 is okay". I don't think Mozilla wants outages either. But... if
Mozilla did say that we should revoke now, that would be great as well. I'd
have a firm answer I can go back with. No risk, but no exception. 

Well except moral risk of course  

-Original Message-
From: dev-security-policy  On
Behalf Of Matt Palmer via dev-security-policy
Sent: Thursday, December 27, 2018 5:55 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Underscore characters

On Fri, Dec 28, 2018 at 12:12:03AM +0000, Jeremy Rowley via
dev-security-policy wrote:
> This is very helpful. If I had those two options, we'd just revoke all 
> the certs, screw outages. Unfortunately, the options are much broader than
that.
> If I could know what the risk v. benefit is, then you can make a 
> better decision? DigiCert distrusted - all revoked. DigiCert gets some 
> mar on its audit - outages seem worse. Make sense?

Given that Mozilla wants CAs to abide by its policies, which include
adherence to the BRs, and you appear to be saying that you'll adhere to the
BRs if you're threatened with distrust... I'd say the logical response from
Mozilla would be to threaten distrust.  I doubt, especially now, that you'll
get a categorical advance "it's OK to not revoke" from Mozilla.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/JAUY6LMmpzDeGtxtOiXLJVWWYjWV65xcMjKoLj_GS
gs=?d=2r4BCPONnLRAQaYxhIYsrR2xI_C73HdzeRvSzxfwF1rOccA0cfq95qcKptTpNVYkGzCfgl
u40QMyhwHQJyWghm9tDreLIrUFB4D0ugqZlnn2SKyEI85b9QcQlb6I-o78NypjSLQRAUF9s9i5tF
sXc6oVsnhZly7GCR8HrTZqfLEL8fXQKwA8A7MRCYPr2Hy61TCorYztrVr2u8IME1WcJdVQxd1tkB
MIgZG8M74du5AO2ELfvkGfV3pBYbOUubjwoFhmqqgsHy5GyDIO_EZS68OavUwfNHvpkZ-5paTSWR
yGwQFw0uz8CKa2kO0IOOBGt55A-WAyvJnhPJScUvwu_c9n2KmEljO7EbvvYGYA0E3Ef6rWWdpZbm
D8FZ39LChfaUgdEP4DX6Y%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
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: Underscore characters

[Jeremy Rowley via dev-security-policy]

> I don't think there's *any* result from all this that everyone would 
> consider desirable -- otherwise we wouldn't need to have this conversation.
+ 1 to that.

> I'm not sure I'd call it "leniency", but I think you're definitely asking 
> for "special treatment" -- pre-judgment on a potential incident so you can 
> decide whether or not it's worth it (to DigiCert) to deliberately break the 
> rules.
I'm not sure there's a policy against asking for special treatment or 
pre-judgment. Like I said, I feel like this is a weird area where I'm not 100% 
sure how to proceed. Like how do you raise when you think obedience to rules 
is riskier than breaking them? Breaking them then explaining why seems like a 
really bad idea. The best I could come up with is ask what to do and see if 
the browsers agree. Acknowledged that this would be very bad in most cases, 
but I'm not sure where you decide?

> What were the criteria by which DigiCert decided which customers to grant 
> exceptions to?  My default assumption is "whichever ones will cost us the 
> most money, on a risk-of-departure-weighted basis, if we revoke their 
> misissued certs", so if DigiCert's criteria was different, I'd be keen to 
> have my assumption changed.
Based on the number of certificates, the reasons the customer identified they 
couldn't make change, and whether revocation would take down a critical site. 
It actually isn't tied to $ at all. The largest issuer of certificates isn't 
on the exception list. Honestly, it came down to which ones were the most mad 
at me for telling them I am going to revoke their certs. I also filed the 
incident reports in that order.

> First off, your customers.  There is a certain amount of exposition in the 
> pharmacy company bug, however I can't say that what's there so far fills me 
> with a sense of contentment.  You said in your most recent post, "Security 
> vulnerabilities are patched based on their rating", and that lacking a CVSS 
> it is difficult to get recognition of a problem.  Would it be fair to say 
> that this narrow approach to security is shared by all/most/some/none of the 
> other similarly situated customers?
No, but it's generally how people can get exceptions to the blackout period. 
More the norm is around how these certs are rolled out. They fall under three 
camps: a) a third party offering the main companies service that requires a 
bunch of testing and permissions (probably contractual), b) complicated 
policies about changes during/around blackout periods and c) certs actually 
used in software that require code changes and deployment to update.

> As an aside, on the subject of "there's no CVSS score for this", let me fix 
> that up, with the official WombleSecure(TM)(R)(Patent Pending) CVSS for 
> "your certs are getting revoked":
https://clicktime.symantec.com/a/1/yUHHbekYeF5I1ApCiRHB3c4GRi5h119CZduhXSUjcHQ=?d=jjXJ8wGMEM-BgSpW3_vhyQL0sXCIhGbj3gBpMQofOamgauLb68trqD6rFgW1WlGMp2x8t2VFcaY0DBIxDVgeeB1NTgFMApldbJMcAgO-QzAYKleHGSG1QMDssL8YiuasGm7sy54zIql5pGoFC32z-FPTIi19g1UDgwcBY97oowWvIdYn96-dpAc9Bgo0beU6KZJB4GgT4nsTYZfQEPWR6iJovigq7cka80r2jfU6Ef-FnpegGAkDENlMwnIoHo4ti6V0kNC1BnXX92EeVaD_XCRNLlzHjHvbe0_9OrBDSAOuXH7r90tkFNs5Jf15Y9tnE-nNgpNo-7ATwrZ6C-AfpSHr9tX-RnCPFHoSUEIJ9az2IiiMo_si4rA2uaMaKtjN1Ziuk7XNO9s%3D=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AN%2FS%3AU%2FC%3AN%2FI%3AN%2FA%3AH%2FE%3AH%2FRL%3AO%2FRC%3AC%2FAR%3AH%2FMAV%3AN%2FMAC%3AL%2FMPR%3AN%2FMUI%3AN%2FMS%3AU%2FMC%3AN%2FMI%3AN%2FMA%3AH
7.5 base, 7.2 temporal, and 8.9 environmental.  All those scores are in the 
"high" band.  "Availability" *is* one of the sides of the security triangle, 
after all.
Lol - thanks. I'll be sure to share this with them.

> Focusing on the "what about next time?" aspect, which I believe is the most 
> important, I'd be interested to know what your customers are planning on 
> changing about their systems and processes, such that if a similar event 
> happens in the future, the outcome won't be the same.
After this, I'd like to talk about removing some of the Symantec roots from 
Mozilla. A lot of these don't need trust in Mozilla and Chrome. The mix is in 
the OS vs. Web ecosystem. They need trust in OS platforms, but Web is more 
optional for a lot of the certs.  If we have roots that are only trusted in 
the two OS platforms (MS and Apple), the risk changes for the web community.

> A similar question applies, even more forcefully, to DigiCert itself. 
> Clearly, whatever you've done so far didn't work, because these customers of 
> yours didn't heed whatever warnings and caveats you provided, and built 
> themselves systems and processes that are unable to comply with their 
> agreements to DigiCert (and, by extension, relying parties).
See above. Also see my response to Ryan on the migration from legacy Symantec 
systems.

> Hence, what is it that DigiCert plans to change, such that an equivalent 
> result cannot happen in the 

RE: Transfer of QuoVadis to DigiCert

[Jeremy Rowley via dev-security-policy]

Longer term, everything is being merged into the DigiCert CPS. For Symantec, 
this will happen during 2019. For Quovadis, I anticipate it’ll happen in either 
2019 or 2020. When we merge the CPS docs depends on when we change the data 
center to be compliant with the DigiCert CPS. For the short term, we plan on 
operating Quovadis under its existing CPS and with its existing practices.

From: Wayne Thayer 
Sent: Tuesday, January 15, 2019 9:10 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Transfer of QuoVadis to DigiCert

Thanks Jeremy.

To be clear, in this case Mozilla policy requires disclosure, but a public 
discussion 'resolved with a positive conclusion' is not required because 
DigiCert is already a member of our program.

The policy also requires notification of any resulting changes in the QuoVadis 
CP or CPS. Jeremy, what CP/CPS changes do you anticipate making? Will QuoVadis 
roots end up under the DigiCert CP/CPS?

- Wayne

On Tue, Jan 15, 2019 at 12:27 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
Hey all,

You may have seen that DigiCert is purchasing the QuoVadis PKI from WISeKey, 
including all public root operations. With the closing date drawing closer, I 
wanted to start the discussion and give the Mozilla community the notice 
required under Section 8 of the Mozilla CA policy.

Let me know what questions you have. I'll do my best to answer them, although 
many of the answers will likely have to wait until the official close date.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org<mailto: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: Transfer of QuoVadis to DigiCert

[Jeremy Rowley via dev-security-policy]

We havent discussed any root removal yet internally.  However, we definitely 
wont be removing the ones used for qwacs.

From: dev-security-policy  on 
behalf of westmail24--- via dev-security-policy 

Sent: Thursday, January 17, 2019 6:55:23 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: Transfer of QuoVadis to DigiCert

Hello,
Do you have planned to remove the QuoVadis  Root certificates and use Digicert 
Root certificates for intermediate certs of QuoVadis or no?
Thanks.
Andrew (Russia)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/TNJhIsNxFy4nlMd_sX4b48PVjFnr0kW5zix2NoSFa5E=?d=-GL3FyJ95r4OVYaTud7Y9gnigJ2YMPhaIe2FR7UY8bfXZy7nW1JBPfStPqoxh_fyTyQweUgNGm3bjtseFxBBexewRHvAxaEHY_aZRRAvFF_mp1sxD4JLzoq3P3DiGl2v_A99uFTtDEdIpkoEsJDOAld4F8qju4C9pujgny3I6nSBJIysPiJULV3Qg7WPSFm5n7G5JnPuY526O_ZWfIUBU-u97c4kdJePVr5gXI1S0tk4uZamQxOAdVUZXVnniT-q37dcWusj_0GcTn66SrxOk2Dm72OOUTwE45n1xGkOvftG6vz6ggg8iJT9Lek8mdbZnuAmdw8S5e3ZOAajLMwdDAMsIvPUcSNb7sKzv9ParpzETIpwimBeDdguKKkLdcIGBbKiowqa7H27EZTbYvQhtdjYKD9lVxn6jbP6gPc%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Transfer of QuoVadis to DigiCert

[Jeremy Rowley via dev-security-policy]

Hey all,

You may have seen that DigiCert is purchasing the QuoVadis PKI from WISeKey, 
including all public root operations. With the closing date drawing closer, I 
wanted to start the discussion and give the Mozilla community the notice 
required under Section 8 of the Mozilla CA policy.

Let me know what questions you have. I'll do my best to answer them, although 
many of the answers will likely have to wait until the official close date.

Jeremy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Underscore characters and DigiCert

[Jeremy Rowley via dev-security-policy]

Hey all, 

 

We're working towards revoking certs with underscore characters in the
domain name, per SC12, but I had a question about legacy Symantec systems
and Mozilla. These particular roots are no longer trusted for TLS certs in
Google or Mozilla, which means the applicability of the BRs is dubious. The
roots are shortly being removed from Microsoft and Apple, although that's
more of an FYI rather than something with direct bearing on the Mozilla
community. If the roots are no longer trusted for TLS in Mozilla, is there
any requirement to revoke the certs issued under those roots?  

 

My initial thought is no as this is similar to what Comodo did with their
request to remove a SHA1 root (and what DigiCert did with one of the Verizon
roots). Note these are still flagged by zlint because they are trusted in
older systems. Because the situation is slightly different with the way
distrust was technically implemented, I wanted to see if there were any
concerns with the community about treating these as private going forward,
similar to the SHA1 roots.  Thoughts?

 

Jeremy 



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: Underscore characters and DigiCert

[Jeremy Rowley via dev-security-policy]

Can we request removal of these roots now? This seems very similar to the
SHA1 situation where CAs requested root removal and then treated the root as
private, regardless of the trust in older platforms. 

-Original Message-
From: dev-security-policy  On
Behalf Of Wayne Thayer via dev-security-policy
Sent: Thursday, December 13, 2018 3:11 PM
To: mozilla-dev-security-policy

Subject: Re: Underscore characters and DigiCert

There are currently no program requirements for roots that have had their
websites trust bit turned off or been removed from NSS, but this is an open
area of concern [1]. When a root is disabled or removed, there is no
protection for Firefox users who haven't updated to a current version, nor
for any of the other consumers of our root store until they update.

However, that doesn't apply here. These roots are still in the Mozilla root
store and trusted for TLS, and some of them will be for quite a while due to
the whitelisted Apple & Google intermediates [2]. It is clear that Mozilla
policy, and in-turn the BRs, still apply to these roots.

Should DigiCert decide not to revoke certificates containing underscores by
the 15-Jan deadline in SC12, including those chaining to distrusted Symantec
roots, I plan to treat it as an incident. As with any incident, full
disclosure is the expectation.

- Wayne

[1] https://github.com/mozilla/pkipolicy/issues/124
[2] https://wiki.mozilla.org/CA/Additional_Trust_Changes#Symantec

On Wed, Dec 12, 2018 at 5:54 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hey all,
>
> We're working towards revoking certs with underscore characters in the 
> domain name, per SC12, but I had a question about legacy Symantec 
> systems and Mozilla. These particular roots are no longer trusted for 
> TLS certs in Google or Mozilla, which means the applicability of the 
> BRs is dubious. The roots are shortly being removed from Microsoft and 
> Apple, although that's more of an FYI rather than something with 
> direct bearing on the Mozilla community. If the roots are no longer 
> trusted for TLS in Mozilla, is there any requirement to revoke the certs
issued under those roots?
>
>
>
> My initial thought is no as this is similar to what Comodo did with 
> their request to remove a SHA1 root (and what DigiCert did with one of 
> the Verizon roots). Note these are still flagged by zlint because they 
> are trusted in older systems. Because the situation is slightly 
> different with the way distrust was technically implemented, I wanted 
> to see if there were any concerns with the community about treating 
> these as private going forward, similar to the SHA1 roots.  Thoughts?
>
>
>
> Jeremy
>
>
___
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: Underscore characters

[Jeremy Rowley via dev-security-policy]

I can break down the date by customer. April 30 was the last date for all 
customers. The actual revocation occurs sometime between Jan 15th and April 
30th (still working on a per cert basis to determine this). Note that we 
actually have the 30 day option available and are recommending it as a 
remediation instead of an exception. We’d prefer customers to move to the 30 
day cert sooner if they can replace the cert but not change the domain name.  
I’ll file a separate incident report per company.

 

Thanks!

Jeremy

 

From: Wayne Thayer  
Sent: Thursday, December 20, 2018 12:25 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: Underscore characters

 

Jeremy,

 

It's good to hear that you do believe you can provide the necessary level of 
information prior to 15-Jan. Given that, I'm now thinking of this as if it were 
a normal incident except that we're moving the reporting prior to the incident 
actually occurring. With 15 affected customers, and perhaps many more 
deployment scenarios, I would ask you to break this into separate incident 
reports per customer as Ryan has previously suggested/requested. I can 
understand the desire to not have 15 separate compliance bugs filed under 
DigiCert for what is arguably the same issue, but I think that reporting 
separately per customer will help to ensure that we receive the level of detail 
needed to assess the hypothetical incident.

 

I'm also not a fan of the proposed 30-April exceptional revocation deadline. 
This provides zero opportunity to employ the 30-day cert option if something is 
missed, and it seems to be an arbitrary date rather than an evaluation of the 
earliest date by which each customer can safely replace their non-compliant 
certificates.

 

- Wayne

 

On Thu, Dec 20, 2018 at 11:16 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Thanks for filing this, Jeremy.

If I understand correctly, the request DigiCert is asking is: "If we
submitted this as an incident report, would it be likely that conversations
about distrusting DigiCert would begin?", and that's what you're trying to
gauge from the community?

I think Wayne's already captured the "We need more information", but I
think it may be helpful to explain the reasoning and thinking here.

The Baseline Requirements and Root Program policies exist for a purpose: To
provide a consistent set of expectations for CAs, which meet the security
needs of the products using or operating those policies. As these policies
tend to call out, a CA may be removed (distrusted) for any reason or no
reason at all - it's entirely at the Program discretion. That said, history
tends to largely see removals for patterns of issues that, in aggregate,
demonstrate an ongoing and significant risk to users and the Internet at
large, although there have been CAs removed for single incidents in the
past - such as key compromise or issuing MITM certificates.

As a CA, the risk is that any and every incident may lead to the CA's
removal, and thus the best path to avoid that is to not have incidents in
the first place. Further, a CA with a pattern of incidents is not wrong to
be even more careful when it comes to presenting new incidents, especially
if they realize that they share similar root causes or further demonstrate
problematic patterns. That's not to say that if you only had a single
incident, you wouldn't be removed - as the policies capture, any reason and
no reason - but on the balance, it has historically tended to be
less-likely that first-time incidents lead to removal.

When incidents happen, it becomes necessary for Root Programs and the
communities they represent or collaborate with to evaluate the details of
the incident, as part of making a determination about what next steps are
appropriate. This involves investigating what the underlying root causes
are, to both ensure that the current CA with the incident understands the
significance, the severity, and the steps to remediate it, as well as to
help the industry at large develop and learn best practices, to prevent
future incidents. We're not the only industry to do this - in many ways,
it's borrowed from the aviation industry, that recognizes that critical
safety functions deserve thoughtful and detailed analysis to prevent harm
coming to those that trust in them.

Incident reports also serve to triage the issues - to work and identify the
risks and make sure they're being mitigated in a timely fashion. Sometimes,
the mitigation of risk may be to remove trust in the CA, other times, there
may be less significant steps that can be taken to address both the
immediate problem and the underlying issues.

DigiCert is now in a precarious position. As a CA, it knows that every one
of its Subscribers have agreed, in some legally binding form, that if the
CA has misissued a certificate, that it MUST be revoked within 24 hours
(or, very recently, and only in some cases, 

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

Thanks Wayne. Happy to update with that information. We’ll try to provide it 
all be end of the year, definitely before Jan 12. I can answer two of these 
generally now:

 

* Reason that publicly-trusted certificates are in use

- They are used on websites and infrastructure accessed through browsers. There 
are some that don’t need to be publicly trusted certificates, but the systems 
still check revocation. If Mozilla blocked the certs, the impact is minimal. If 
the certificates are revoke, the infrastructure goes down. Would you like me to 
identify which ones could be blocked by Mozilla vs. revoked?

 

* Reason that the provision for 30-day certificates isn't helpful

- The blackout periods don’t allow any change in infrastructure so replacing 
the certificates is just as difficult as changing the domain names. Even large 
non-tech companies don’t have a ton of automation so it’s not surprising that 
they’ll need more days to replace the certs if their blackout period ends the 
12th.

 

Of course, I’ll provide further information in the incident report as more 
specific information comes in.

 

From: Wayne Thayer  
Sent: Thursday, December 20, 2018 9:04 AM
To: Jeremy Rowley 
Cc: r...@sleevi.com; mozilla-dev-security-policy 

Subject: Re: Underscore characters

 

Jeremy,

 

On Wed, Dec 19, 2018 at 10:55 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Done: 



https://bugzilla.mozilla.org/show_bug.cgi?id=1515564

Thanks for submitting this. 



It ended up being about 1200 certs total that we are hearing can’t be replaced 
because of blackout periods.

These 1200 are only the ones that can't be replaced by Jan 15th and will cause 
outages if revoked then?

 

I don't think the information you've supplied is anywhere close to what Ryan 
asked for or what the community needs in order to make the decision you're 
asking for. I'm looking for specifics on why every cohort (i.e. every 
deployment scenario for every customer requesting an extension) of these 
certificates can't be revoked, such as:

* Specific per-customer change freeze dates and the rationale for them

* Explanations of the effort and risk involved in replacing them

* Reason that publicly-trusted certificates are in use

* Reason that the provision for 30-day certificates isn't helpful

 

Only with this information can we have some assurance that any exceptions are 
limited to the bare minimum and that we're able to learn and improve.

 

Without this information, we're still in the situation of blindly trusting 
DigiCert to do the right thing, which is no different than having a CA report 
an incident after the fact.

 

Is it realistic to expect that you can provide the level of detail that Ryan 
and I are requesting prior to 15-Jan?

 


From: Ryan Sleevi mailto:r...@sleevi.com> > 
Sent: Wednesday, December 19, 2018 11:05 AM
To: Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: r...@sleevi.com <mailto:r...@sleevi.com> ; mozilla-dev-security-policy 
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Re: Underscore characters



Look forward to seeing and discussing once the full scope of the request is 
shared.



On Wed, Dec 19, 2018 at 12:21 PM Jeremy Rowley mailto:jeremy.row...@digicert.com>  <mailto:jeremy.row...@digicert.com 
<mailto:jeremy.row...@digicert.com> > > wrote:

We will post the full list of exceptions today. 



One of the big factors should be the risk to the industry/community if the 
certificates aren’t revoked. Perhaps we can identify what the risk to the 
community is in revocation delays first? There’s no need to know the exact 
certs to talk about what the risk associated with underscore characters is. 
Could you please explain the risk to the community in a revocation delay as the 
“unreasonable” argument isn’t really supported without that understanding. 



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: Underscore characters

[Jeremy Rowley via dev-security-policy]

Hey all, 

 

Here’s the first of the companies. Figured I’d do one and see if it has the 
information you want. 

 

https://bugzilla.mozilla.org/show_bug.cgi?id=1515788

 

I think this answers all of your questions (except Ryan’s question about 
remediation). Could you let me know if more detail is required or if you’d like 
additional info included?

 

Thanks!

Jeremy

 

 

From: Wayne Thayer  
Sent: Thursday, December 20, 2018 12:25 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; mozilla-dev-security-policy 

Subject: Re: Underscore characters

 

Jeremy,

 

It's good to hear that you do believe you can provide the necessary level of 
information prior to 15-Jan. Given that, I'm now thinking of this as if it were 
a normal incident except that we're moving the reporting prior to the incident 
actually occurring. With 15 affected customers, and perhaps many more 
deployment scenarios, I would ask you to break this into separate incident 
reports per customer as Ryan has previously suggested/requested. I can 
understand the desire to not have 15 separate compliance bugs filed under 
DigiCert for what is arguably the same issue, but I think that reporting 
separately per customer will help to ensure that we receive the level of detail 
needed to assess the hypothetical incident.

 

I'm also not a fan of the proposed 30-April exceptional revocation deadline. 
This provides zero opportunity to employ the 30-day cert option if something is 
missed, and it seems to be an arbitrary date rather than an evaluation of the 
earliest date by which each customer can safely replace their non-compliant 
certificates.

 

- Wayne

 

On Thu, Dec 20, 2018 at 11:16 AM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Thanks for filing this, Jeremy.

If I understand correctly, the request DigiCert is asking is: "If we
submitted this as an incident report, would it be likely that conversations
about distrusting DigiCert would begin?", and that's what you're trying to
gauge from the community?

I think Wayne's already captured the "We need more information", but I
think it may be helpful to explain the reasoning and thinking here.

The Baseline Requirements and Root Program policies exist for a purpose: To
provide a consistent set of expectations for CAs, which meet the security
needs of the products using or operating those policies. As these policies
tend to call out, a CA may be removed (distrusted) for any reason or no
reason at all - it's entirely at the Program discretion. That said, history
tends to largely see removals for patterns of issues that, in aggregate,
demonstrate an ongoing and significant risk to users and the Internet at
large, although there have been CAs removed for single incidents in the
past - such as key compromise or issuing MITM certificates.

As a CA, the risk is that any and every incident may lead to the CA's
removal, and thus the best path to avoid that is to not have incidents in
the first place. Further, a CA with a pattern of incidents is not wrong to
be even more careful when it comes to presenting new incidents, especially
if they realize that they share similar root causes or further demonstrate
problematic patterns. That's not to say that if you only had a single
incident, you wouldn't be removed - as the policies capture, any reason and
no reason - but on the balance, it has historically tended to be
less-likely that first-time incidents lead to removal.

When incidents happen, it becomes necessary for Root Programs and the
communities they represent or collaborate with to evaluate the details of
the incident, as part of making a determination about what next steps are
appropriate. This involves investigating what the underlying root causes
are, to both ensure that the current CA with the incident understands the
significance, the severity, and the steps to remediate it, as well as to
help the industry at large develop and learn best practices, to prevent
future incidents. We're not the only industry to do this - in many ways,
it's borrowed from the aviation industry, that recognizes that critical
safety functions deserve thoughtful and detailed analysis to prevent harm
coming to those that trust in them.

Incident reports also serve to triage the issues - to work and identify the
risks and make sure they're being mitigated in a timely fashion. Sometimes,
the mitigation of risk may be to remove trust in the CA, other times, there
may be less significant steps that can be taken to address both the
immediate problem and the underlying issues.

DigiCert is now in a precarious position. As a CA, it knows that every one
of its Subscribers have agreed, in some legally binding form, that if the
CA has misissued a certificate, that it MUST be revoked within 24 hours
(or, very recently, and only in some cases, 5 days). The CA has a duty and
obligation to their customers, the Subscribers, to make sure that they
understand this. This is not about a 

RE: Statement on the Sunset of Underscore Characters

[Jeremy Rowley via dev-security-policy]

But this part isn't true "Browsers are not capable of granting 'exceptions' to 
the Baseline Requirements", at least for Mozilla. See the Mozilla auditor 
requirements for example.  Perhaps better stated that they don't have to 
implement the standards they don't like?

-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Friday, December 21, 2018 2:22 PM
To: Wayne Thayer 
Cc: mozilla-dev-security-policy 
Subject: Re: Statement on the Sunset of Underscore Characters

On Fri, Dec 21, 2018 at 1:54 PM Wayne Thayer via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Since a number of questions and concerns have been raised regarding 
> the sunset of underscore characters in dNSNames, I would like to 
> summarize Mozilla’s position on the issue as follows:
>
> In early November, the CA/Browser Forum passed ballot SC12 [1], 
> creating a sunset period aimed at ending the practice of placing 
> underscore characters
> (“_”) in the subjectAlternativeName (SAN) attribute of 
> publicly-trusted TLS certificates. The ballot requires revocation of 
> most existing certificates with underscore characters in SANs before 
> 15-Jan 2019, but allows continued use of these certificates through 
> April 2019 if they are valid for less than 30 days.
>
> A thorough review of RFC 5280 and its references shows that underscore 
> characters have never been permitted in dNSNames in the SAN of 
> compliant certificates. However, for many years this was a commonly 
> accepted practice, and all major browsers currently ignore this requirement.
>
> In 2017, a ballot that attempted (among other things) to create an 
> exception to RFC 5280 for these certificates [2] in the CA/Browser 
> Forum Baseline Requirements was rejected [3], in-part due to 
> objections to this exception. At that time, some CAs decided to stop 
> issuing these certificates, while others continued. When the situation 
> resurfaced earlier this year, there was spirited debate about how best 
> to resolve the problem, and the compromise defined in ballot SC12 
> eventually emerged as the most viable approach.
>
> Mozilla has been asked by users of these certificates - primarily in 
> the financial services industry - and their CAs to make exceptions to 
> extend the revocation deadline until their systems can be updated. We 
> don’t have the power to unilaterally change the Baseline Requirements 
> (only the CA/Browser Forum can do that), but Mozilla can take a 
> position on our plans to enforce them. However, simply granting CAs a 
> “free pass” to ignore the revocation requirement is, we believe, not 
> in the best interest of our users, fundamentally because it sets the 
> expectation that the Baseline Requirements are negotiable. It is also:
> * unfair to CAs who voted in favor of ballot SC12 under the assumption 
> that it would be enforced
> * unfair to the CAs who avoided this situation by ending this practice 
> last year
> * unfair to the CAs (and their impacted customers) who will revoke all 
> these certificates on time
>
> This doesn’t mean that we are insensitive to the potential disruption 
> caused by the revocation of this type of certificate.
>
> We sincerely hope that affected organizations make every effort to 
> meet the revocation deadline. If that is not possible for each and 
> every certificate containing an underscore in the SAN, our expectation 
> is for CAs to treat any failure to adhere to ballot SC12 as a policy 
> violation. Should a CA choose not to revoke certificates with 
> underscores in a SAN prior to 15-January 2019, we expect the 
> individual circumstances that led to the decision for each Subscriber 
> organization to be provided in a detailed incident report.[4] For this 
> situation, we prefer for the incident report to be submitted 
> immediately so that the Mozilla community can make our best effort to 
> evaluate the information and identify any gaps or unmet expectations 
> before the 15-January revocation deadline. We believe that this 
> approach creates the best incentives to balance the various risks and 
> to maximize disclosure, and in so doing helps us to improve the 
> trustworthiness of the web PKI.
>

(In a Chrome capacity)

Thanks for sharing this, Wayne.

On behalf of Chrome, we want to echo our support for this statement and the 
expectations, and believe it is consistent with our expectations on the matter.

To emphasize a few specific points here: Browsers are not capable of granting 
"exceptions" to the Baseline Requirements. We, Chrome, expect any violations 
identified by CA management or their auditors to be disclosed within their 
audit reports, management letters, and to the broader community, the principles 
of which are captured in our Root Certificate Policy [A]. We expect there to be 
a public incident report and discussion, to ensure that the information 
necessary to ensure that the scope of the issue has been 

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

I don’t think I’m arguing that CAs should ever ignore the BRs. I’m arguing that 
deciding the consequences of failing to follow the BRs falls in the hands of 
the browsers.  But I think you definitely highlighted why this discussion is 
confusing. I think all agree on the following:

1.  Failure to revoke by Jan 15th is a non-compliance with the BRs. 
2.  Non-compliances require an incident report
3.  The incident should appear on the audit report. Side note – there won’t 
be audit criteria around this particular issue by the time all certs are 
revoked. We’re planning to inform our auditor of course (already have in fact), 
but without audit criteria any delay in issuance essentially goes undetected 
unless someone in this community notices. Because the audit criteria won’t be 
updated until well after our audit report, if we were a bad acting CA, the 
incident would just never show up.

 

I think the only thing we disagree on is:

4.  Can the browser say what happens for a failure to comply with the BRs 
before the failure happens. 

 

Is that a fair assessment?  I see why you wouldn’t want to engage in the 
question you asked (“Hypothetically, what would happen if we did (Bad Thing 
X)". That would be terrible. Much better to treat this question as “We know X 
is going to happen. What’s the best way to mitigate the concerns of the 
community?”  Exception was the wrong word in my original post. I should have 
used “What would you like us to do to mitigate when we miss the Jan 15ht 
deadline?” instead. Apologies for the confusion there. 

 

Jeremy

 

From: Ryan Sleevi  
Sent: Wednesday, December 26, 2018 10:00 AM
To: Jeremy Rowley 
Cc: dev-security-policy@lists.mozilla.org
Subject: Re: Underscore characters

 

 

 

On Wed, Dec 26, 2018 at 11:13 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hey Matt, 

The trust stores are always free to ignore the CAB Forum mandates and make 
their own rules. Mozilla has in the past (see the Mozilla audit criteria 
exception for other audits outside of Webtrust and ETSI). The root stores are 
also the entities that determine what happens if the rules are violated. Thus, 
we're asking what the violation of this revocation timeline results in and 
whether Mozilla is enforcing the CAB Forum requirement. The browsers always 
decide the risk they want to bear and when that risk becomes unacceptable. The 
question we're asking is whether this particular mis-revocation provision would 
amount to unacceptable risk to the browsers.  

I don't think we're asking browsers to take on any risk. In fact the opposite. 
The risk of revocation is a browser outage for that website. A delay in 
revocation gives the operator for specifically issued certificates gives them 
more time to avoid an outage. Thus, risk is mitigated. A poor explanation, but 
I think we have to identify what the risk is before browsers can say they are 
taking on anything additional. The "CAs may be doing bad things in the dark" 
allegation can't be responded to because it's too vague. I'm also troubled to 
think that might be a concern as our policy is to over-report issues. Plus, 
that risk is pretty hard to sell to management as an immediate threat requiring 
replacement of their certificates. This lack of definition on the problem is 
also the main difference between this event and a compromised key. Explaining 
key compromise to executive management for an emergency exception to a blackout 
period is a lot different than explaining why hundreds of certificates require 
replacement because they contain underscores. I think everyone would benefit 
(myself included) if I could get more information about why underscore 
characters themselves present an actual risk. If we could get a statement on 
that, you'd see a lot less confusion.

Jeremy

 

Jeremy,

 

While I can't speak for Wayne, I tried to highlight how dangerous and 
problematic this thinking is and framing. By framing it as you have, it makes 
it much more difficult to see this as a productive discussion about handling 
revocation following an incident, and instead about a CA arguing that they 
should be able to ignore the BRs at will. I'm sure you can see how that latter 
framing is especially problematic, and I think arguments that try to present it 
as such have a chance at steering the conversation very negatively.

 

You've heard from two browsers at least (Mozilla and Google) that they expect 
an incident report, which means that they are enforcing the Baseline 
Requirements and do view this as non-compliance by a CA. There is no exception 
being granted - it's non-compliance. Further, the discussion you're looking to 
have is seemingly not about whether this particular incident is problematic 
in-and-of-itself, even though you've framed it as such here, but instead 
whether the pattern and set of incidents represents a concern about the ongoing 
ri

RE: Underscore characters

[Jeremy Rowley via dev-security-policy]

Hey Matt, 

The trust stores are always free to ignore the CAB Forum mandates and make 
their own rules. Mozilla has in the past (see the Mozilla audit criteria 
exception for other audits outside of Webtrust and ETSI). The root stores are 
also the entities that determine what happens if the rules are violated. Thus, 
we're asking what the violation of this revocation timeline results in and 
whether Mozilla is enforcing the CAB Forum requirement. The browsers always 
decide the risk they want to bear and when that risk becomes unacceptable. The 
question we're asking is whether this particular mis-revocation provision would 
amount to unacceptable risk to the browsers.  

I don't think we're asking browsers to take on any risk. In fact the opposite. 
The risk of revocation is a browser outage for that website. A delay in 
revocation gives the operator for specifically issued certificates gives them 
more time to avoid an outage. Thus, risk is mitigated. A poor explanation, but 
I think we have to identify what the risk is before browsers can say they are 
taking on anything additional. The "CAs may be doing bad things in the dark" 
allegation can't be responded to because it's too vague. I'm also troubled to 
think that might be a concern as our policy is to over-report issues. Plus, 
that risk is pretty hard to sell to management as an immediate threat requiring 
replacement of their certificates. This lack of definition on the problem is 
also the main difference between this event and a compromised key. Explaining 
key compromise to executive management for an emergency exception to a blackout 
period is a lot different than explaining why hundreds of certificates require 
replacement because they contain underscores. I think everyone would benefit 
(myself included) if I could get more information about why underscore 
characters themselves present an actual risk. If we could get a statement on 
that, you'd see a lot less confusion.

Jeremy


-Original Message-
From: dev-security-policy  On 
Behalf Of Matt Palmer via dev-security-policy
Sent: Thursday, December 20, 2018 4:54 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Underscore characters

On Thu, Dec 20, 2018 at 10:34:21PM +0000, Jeremy Rowley via dev-security-policy 
wrote:
> Here’s the first of the companies. Figured I’d do one and see if it has the 
> information you want. 
> 
> https://clicktime.symantec.com/a/1/Vso73rFeURLZ94HBeuxBLdmk1isdwCRJ1YP
> CMFAxstM=?d=I3ucqXub-yr0TW9Ocbs-YTBkM2F0beNtptvGgqlq3YEDH6Fzq26eV5Vign
> YLpVcHu_P3Gdnnz-qiPqcKis3N25Fp-2RGfSxyMcVFVUNXL4_EQlFrw0BYTZpuPCQdk5mm
> -nSlrDH6uc4OgNw1QYDQACt6RPMqV8qWIioLa1QehqMa3nJlcGcR8b3abEqcOYnxwAZBxE
> lxsBIDqHumeVxhaczrPgjNCOobWmoaqVYwIp9ZGyEADoOrpFVhL_p7uYKkSi1JVOAePuQg
> WB8Xu_QHkdm22N_ZkxRxbBdD1Jc0xy4YuXr58Tfv96bX0LGUeM69JWT8_jRwCLwOPgMJXW
> pRNZec6GRDumz3V2itO4ujx1MRsegZuKhuwUOxc3M0QrEHr734ym37mw%3D%3D=https
> %3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%3D1515788

Complete side-note: when the customer said you couldn't identify them by name, 
did they know you were going to be linking to a whole pile of certificates with 
their organizationName in them?  

> I think this answers all of your questions (except Ryan’s question 
> about remediation).  Could you let me know if more detail is required 
> or if you’d like additional info included?

The question that comes to my mind most of all is tangentially related to 
Ryan's question around long-term remediation, but I'll ask it anyway as it's at 
least somewhat independent.

You state in the bug you linked that "[The certificates] can't be replaced 
before [April 30, 2019] because of the code freeze and the risk of an outage".  
That is an absolute statement, which I take to mean that there is
*no* possibility of certificates being replaced in the freeze period (Oct 
15-Feb 1).

So, my question is: what would this organization do if they had suffered a key 
compromise (to take one possible reason for immediate revocation, which happens 
to be forefront in my mind) on Oct 16?  Would this organization continue to use 
a certificate which uses a known-compromised key until possibly as late as 
April 30 -- which, if my counting-on-fingers is correct, is approximately six 
and a half months?  Would DigiCert consider not revoking the certificate with a 
compromised key for that long, if the customer asked them to?  Would DigiCert 
expect trust stores to bless that decision?

If the answer to the above questions is "no, of course not!" (as I would 
sincerely hope they would be), then your absolute statement that the 
certificates "*can't* be replaced" should probably read something more like 
"the organization would prefer not to replace the certificates before then, 
because it is a lot of work and entails some degree of risk".  Which takes us 
back to the calculus of options:

1. DigiCert revokes, organizati

Re: SSL private key for *.alipcsec.com embedded in PC client executables

[Jeremy Rowley via dev-security-policy]

I think pretty much every ca will accept a signed file in lieu of an actual 
key. Generally provide the key just means some proof of compromise the ca can 
replicate.

From: dev-security-policy  on 
behalf of Matt Palmer via dev-security-policy 

Sent: Monday, December 10, 2018 11:39:31 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: SSL private key for *.alipcsec.com embedded in PC client 
executables

On Tue, Dec 11, 2018 at 05:37:41AM +, Xiaoyin Liu via dev-security-policy 
wrote:
> It’s clear that the private key for *.alipcsec.com is embedded in the
> executable,

There are ways of implementing SSL such that the private key doesn't *have*
to be stored locally.  They all require the TLS termination point to be able
to communicate with the service that *does* hold the private key, so a good
way to test that the key is stored locally is to remove external
connectivity and then try to establish a TLS connection.  If you still can,
the key has to be *somewhere*.

> packed by VMProtect, and the process has anti-debugging protection.  I
> tried plenty of methods to extract the private key, but didn’t succeed.  I
> reported this to Alibaba SRC anyway.  They replied that they ignore this
> issue unless I can successfully extract the key.

That sounds like it might be an admission that the binary *is* in the
executable, and they're just hoping you won't be able to get it.

> So is this a certificate misuse issue, even if the private key is
> obfuscated?  If so, do I have to extract the private key first before the
> CA can revoke the cert?

Sadly, some CAs do indeed require you to *actually* produce the private key
in order for them to consider the key compromised.  Given that people can
pull apart Nation-State grade malware I think "we don't *know* that anyone's
found it yet" is lamentably short-sighted, but absent an explicit rule that
a key is considered compromised if it can be shown that it *must* be in
a local executable, some CAs will continue to stick to their current
standards.

You can see how a similar situation played out in the past, in
https://clicktime.symantec.com/a/1/z7t2f8C-xqcp0GyPdbPYq0AzStbSzZZLsAiWkgf1Qao=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2Fpk039T_wPrI%2FtGnFDFTnCQAJ

However, I don't know what GlobalSign's policy is regarding revocation
proof.  Rather than just talking to Alibaba, it would be worth contacting
GlobalSign's problem reporting address (which is listed in the problem
reporting list in the CCADB, at
https://clicktime.symantec.com/a/1/Q235mwJymdbdGiH8YOe0XcXtTxxDAnyPflk1ft55vMI=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D=https%3A%2F%2Fccadb-public.secure.force.com%2Fmozilla%2FAllProblemReportingMechanismsReport)
and putting the situation to them.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/0DB1rX6Nb0O0ODt9aZeLn-fDlAWawyUHF7uk_TFf9aU=?d=wSt3-FOUxECayz11Nt0P1X794-iSgW_g8FHinkPNGP7yfJPdd43QxrqJq3ndOpqrfgFw_4kll_w4koZ4Fmhjm-pcmi1trfuhDJqNhLBZkLi3TtVf47PYEeawoI-Mpx8DGzrTx5czVUdsV-RH1iiNRrYjkCzYnHRhDFHmso6ZD7x37NwvEAjNwTwDRwm8lYv0D0UMvBq4vgoqr5pH26lNrieRBNTT0qsApxp-JlfSw6GRoBhhI0oO4mfoXv7xBpYCP1UeKy330eCmN67TFaqUHmXGdFgWj4ZubHj8J6W24Jf4MpGU1ux-HGd0zFGdQNELTXDP8jIbA_mr_P7ZJ2cUzEcCUC3XkhmjEZ5ioLZvmfl0I_BLAeIr1AifJapBnpkdWJwvXTCfadOvB7ehq5XKKIvwne6LkOxTK8KgWL_I7al_WgtjU6FoRr9ftMQgvGT_Xp2Z_OCQJA%3D%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: s/MIME certs and authentication

[Jeremy Rowley via dev-security-policy]

This is one of the reasons I wanted to raise the issue. Issuing the cert and
delivering to the email seems like a pretty common way to verify email certs
(either you have access to the email or you don't), but this is backwards
from TLS. Is this particular process a violation of the Mozilla policy?

Mozilla policy, Section 2.2 #2:
"For a certificate capable of being used for digitally signing or encrypting
email messages, the CA takes reasonable measures to verify that the entity
submitting the request controls the email account associated with the email
address referenced in the certificate or has been authorized by the email
account holder to act on the account holder's behalf. The CA's CP/CPS must
clearly specify the procedure(s) that the CA employs to perform this
verification."

There's nothing that specifies the cert must be issued after the verifying
control or that issuance can't be part of the verification process. Although
this seems backwards, I still think it's compliant with the Mozilla policy. 


-Original Message-
From: dev-security-policy  On
Behalf Of Matt Palmer via dev-security-policy
Sent: Thursday, December 13, 2018 2:39 PM
To: dev-security-policy@lists.mozilla.org
Subject: Re: s/MIME certs and authentication

On Thu, Dec 13, 2018 at 09:50:21AM -0800, pedro.wisekey--- via
dev-security-policy wrote:
> For S/MIME capability itself, we are required to ensure that "the 
> entity submitting the request controls the email account associated 
> with the email address referenced in the certificate", so by merely 
> making the process to require the user to access his email account to, 
> for example, download the renewed certificate it seems to be enough, 
> as any other method like a bounce-back message could probably get to the
same result.

That seems rather backwards.  You're issuing the certificate and *then*
validating control of the e-mail address.  I doubt that issuing a TLS server
certificate and then performing domain control validation would be
considered acceptable, and I don't imagine there's enough of a difference in
S/MIME certificates to make it acceptable for those, either.

- Matt

___
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: DigiCert Assured ID Root CA and Global Root CA EV Request

[Jeremy Rowley via dev-security-policy]

* The TERENA SSL CA 3 subordinate has misissued a number of certificates [3], 
most of which are not revoked. 

- We can revoke these. I have no issue remediating them.  I didn’t realize 
these were an ongoing concern. 

 

*  DigiCert’s response in this bug states “We were under the impression from 
previous communications with Mozilla that certain types of errors identified 
did not require certificate revocation. It would help if Mozilla could indicate 
which certificate errors are believed to require revocation. We will then 
review the lists to see which certificates need to be revoked.” I do not 
believe that Mozilla should create such a list, and we have set a precedent for 
requiring revocation for at least some of the errors that are identified - e.g. 
metadata in subject fields [4].

- That’s fine, but the answer still stands as why we didn’t revoke them before. 
Gerv told us we didn’t need to revoke them because they didn’t represent an 
actual security concern. I can go find the email if that helps.


* In addition, DigiCert previously reported that they had addressed the problem 
of metadata in subject fields for certificates issued by the Terena subordinate 
[5].

- Yes. This should be addressed. Unless you are expecting them to be revoked 
now? 



* Linters identify a large number of misissued certificates under the DigiCert 
SHA2 Secure Server CA intermediate [6]. Many of these are false positives (e.g. 
ZLint expects CN and SAN fields to be lowercased), but some are not and of 
those many are not revoked - e.g. [7].


Thanks a ton for the breakdown. We’ll get these taken care of where it’s not a 
false positive. I think there are only 2-3 that are not false positives, with 2 
not previously discussed. 

 

Here’s the breakdown:


   FATAL: x509: RSA modulus is not a positive number 



Bad reading of the BRs. The BRs say the range should be between 2^16+1 and 
2^256-1. The team implementing this thought saw SHOULD and thought it was 
optional. They missed the sentence before which says the public exponent MUST 
be equal to 3 or more. I’ll file and incident report on this.

 

 


   FATAL: asn1: structure error: integer not minimally-encoded 

 


I think this one is a false positive? It’s caused by padded zeros which  aren’t 
expressly prohibited. Want us to revoke these?

 

 


 ERROR: The common name field in subscriber certificates must include only 
names from the SAN extension 

This one is a false positive

 

ERROR: DNSNames must have a valid TLD

This is a false positive

 

ERROR: The 'Organization Name' field of the subject MUST be less than 64 
characters

This is one of the issues mentioned above. We can revoke all of these. We 
didn’t know Mozilla was waiting on that.

 


 

ERROR: CAs MUST NOT issue subscriber certificates with validity periods longer 
than 39 months regardless of circumstance.

False positive

 

 ERROR: The country name field MUST contain the two-letter ISO code for the 
country or XX 

Grr.. I dislike this one (XK was used instead of XX). Although recognized as a 
temporary code for Kosovo, technically XK is not an official ISO code so it 
violates the strict letter of the law. We’ll revoke these.

 

ERROR: Subject name fields must not contain '.','-',' ' or any other indication 
that the field has been omitted 

False positive. The BRs say “All other optional attributes, when present within 
the subject field, MUST contain information that has  been verified by the CA. 
Optional attributes MUST NOT contain metadata such as ‘.’, ‘-‘, and ‘ ‘ (i.e. 
space)  characters, and/or any other indication that the value is absent, 
incomplete, or not applicable.” With the strict wording policy that seems in 
effect, organizationalUnit is not “All other optional attributes”. It’s a 
defined attribute and thus cannot be “other”.

 

ERROR: Explicit text has a maximum size of 200 characters

False positive I think…. 

 

 


ERROR: Subscriber Certificates issued after 1 July 2016 but prior to 1 March 
2018 MUST have a Validity Period no greater than 39 months. 

 


False positive

 

 ERROR: Subscriber Certificate: subject:localityName MUST appear if 
subject:organizationName, subject:givenName, or subject:surname fields are 
present but the subject:stateOrProvinceName field is absent. 

 


Wow. I hadn’t seen this. It’ll be revoked and we’ll look at what happened.

 

 

* CPS section 3.2.2 did not, in my opinion, adequately specify the procedures 
employed to perform email address verification as required by Mozilla policy 
section 2.2(2). The latest update addressed this.
- This is an issue related to the fact there is no policy on s/MIME. We updated 
it with more specificity, of course, but I’d love to see a real s/MIME policy.

 

Thanks Wayne. I can confirm we will revoke all mis-issued certs.

 

 

From: Wayne Thayer  
Sent: Thursday, December 13, 2018 5:34 PM
To: Jeremy Rowley 
Cc: Ryan Sleevi ; mozilla-dev-security-policy 

Subject: Re: 

RE: DigiCert Assured ID Root CA and Global Root CA EV Request

[Jeremy Rowley via dev-security-policy]

We can revoke them all by then. The question is do the browsers really want us 
to? 

Since we started a public discussion, here's the details:

There are several prominent websites that use certs with underscore characters 
in connection with major operations. I was hoping to get permission to post the 
names of these companies before I started a public discussion, but se le vie - 
the discussion already started. These companies are currently in their blackout 
period which ends around mid-Jan. We're scheduled to revoke on Jan 14th per the 
BR change. However, we've heard back from several of them that they won't 
complete the migration by then. This will take down several of the Fortune 
500's websites for a change in the BRs that no one can understand. What we're 
wondering is how the browsers feel about revocation vs. shutting down the 
sites. Public discussion is welcome while I still try to get the names. 
Unfortunately, most companies of that size require a legal review of the 
communication before we can post their name...


-Original Message-
From: dev-security-policy  On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, November 29, 2018 12:19 PM
To: Wayne Thayer 
Cc: mozilla-dev-security-policy 
Subject: Re: DigiCert Assured ID Root CA and Global Root CA EV Request

This deadline is roughly five weeks before all underscore certificates must be 
revoked (per Ballot SC12). Given the number of underscore certificates under 
various DigiCert operated hierarchies, would you think it appropriate to 
consider whether or not SC12 (and, prior to that, the existing BR requirements 
in force when those certificates were issued) was followed by that date?

More concretely: If DigiCert were to fail to revoke certificates by that 
deadline, would it be a reason to consider denying EV status to these roots / 
removing (if a decision is made to grant) it?

I realize the goal is to close discussion a month prior to that date, but I 
suspect such guidance about the risk of failing to abide by SC12, and failing 
to revoke by January 15, would be incredibly valuable to DigiCert and their 
customers.

On Thu, Nov 29, 2018 at 1:39 PM Wayne Thayer via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

> Reminder: the 3-week discussion period for this request to EV-enable 
> two DigiCert roots ends next Friday 7-December.
>
> - Wayne
>
> On Fri, Nov 16, 2018 at 5:00 PM Wayne Thayer  wrote:
>
> > This request is to enable EV treatment for the DigiCert Assured ID 
> > Root
> CA
> > and DigiCert Global Root CA as documented in the following bug:
> > https://clicktime.symantec.com/a/1/adm9pTelz2Ycom-02ypNzTJ8tHbaHBnhr
> > 4KpinQCwlc=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv=https%3A%2F%2Fbugzilla.mozilla.org%2Fshow_bug.cgi%3Fid%
> > 3D1165472
> >
> > * BR Self Assessment is here:
> > https://clicktime.symantec.com/a/1/yUphkRZlY4hiWQzfLqXz_e6_F7P6T9IN6
> > gvhgZ8YgRI=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8960346
> >
> > * Summary of Information Gathered and Verified:
> > https://clicktime.symantec.com/a/1/25vbrlC4oNIH-rmRpBBOoNpXg9-MyHD3b
> > Arsg3rBYtU=?d=zggbfQ2UquIn-SV-ucU3iLEdxhFMiq9MN3zVHKS1lUo4wrDAUuqZ60
> > I9shljs32UPhv8ZKpenr8hGgACWBJQrC9TNT4MdeUNlx4r0FqYnMxjtk9I9D49tOkWtZ
> > wj0sxrbkFcuZl85ZMSfeIlCdKJ96uNLEdf69FG7V89Toz5h22AkEfM_tEXPrs3ti_Yzn
> > whbxUEM3Sl81xgMn2mpjaK7cCHEKPqRh8Dn_R4vcnJy6zt5RgUOFuv1qN6pb42VMrWou
> > Oh1_O4h9kg5tdN2MXZWioTc_3R_vMMU9o2nZiqPiouWRNjh4TEGzFOR8SlK0FjgcpInY
> > iEi2JE0QsZhnVjv7YlCCPUTD2FS8gGmmV2uvocQ50Z2diXYy3hVHEUMrM60G6enQ8T53
> > MtwMtvuAgtBBYQhASQcVfUJLruxU2rEDumYU2H0S1WsiMlCf8oIda7Z3kTsfw77J6kIe
> > JAcE67idnv=https%3A%2F%2Fbug1165472.bmoattachments.org%2Fattachmen
> > t.cgi%3Fid%3D8987141
> >
> > * Root Certificate Download URLs:
> > ** Global: https://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt
> > ** Assured: 
> > https://www.digicert.com/CACerts/DigiCertAssuredIDRootCA.crt
> >
> > * CP/CPS:
> > ** CP:
> > 

Re: CA Communication: Underscores in dNSNames

[Jeremy Rowley via dev-security-policy]

Personally, i think you should continue the discussion here. Although you can 
bring it up to whichever ca you use, the reality is that without the browsers 
knowing why the certs cant be replaced and the number, theres no way to gauge 
their reaction to a non compliance. The penalties may include root removal (see 
symantec) so I doubt many cas would be willing to risk a qualification without 
clear guidance from the browsers on the risk associated with the non compliance.

From: dev-security-policy  on 
behalf of pilgrim2223--- via dev-security-policy 

Sent: Friday, December 7, 2018 8:26:42 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: CA Communication: Underscores in dNSNames

Thank you very much for your response!

So at the end of the day I will not get any relief from the browsers, and will 
need to get an exception from my CA?

When I asked the CA they told me to take it here. Feels like the CA is where 
I'm going to have to focus!

Thanks again for your time!

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://clicktime.symantec.com/a/1/nN3YNjTD37Z9bk8efCYXsWHpyw8ViK61Q8Dz1AzUtno=?d=cQ4KQMo02NQvJ7GQxkZHfn9YbOkOTiGLFwgAhzovU-ksifF97AFzeTEl3fKU1c4flMJM5MQa4SYfNOuCB5-Y29jyEtL2_9KBxlVmHB_-8X_yPT3Gd1KBASJgcwXjKaIjjc7h8rFYLmo4FmmjdQDJfQcxl_q00tAfBZTdTqkwLD4b__i1PLIwekimsAKnCEc7M1LQPr1uSNB-FjHnEcF14WbG_18ILSXzHM34tK_cdKnINlfFOEvMSGXK7LVBeRjiRGTuodckiUppT5eIbtRZNKo6R8hoXcUzy-yTZ21EbW651pPGEqEwRb1Qpu9J0tLL6DExVNq6euprfMtWQTwjpQGvzkg5KO26pXSnafFpMBxblo_G0EcAZEMPzGWZrQxxtD8_wSHTTO7-9MbzrQGF8qAWuuFbGW-M220s2HRhgU8qz_qZtto%3D=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: CA Communication: Underscores in dNSNames

[Jeremy Rowley via dev-security-policy]

I only ask because telling people to go back to the CA and work something out 
isn’t a great answer when the retort is that the CA will be distrusted if they 
don’t. Either the customer doesn’t replace all their certs and they are made 
non-functional by revocation or the certs are distrusted because the CA isn’t 
operational anymore. Telling people to go have the CA cover the risk when those 
are the two options seems like we’re avoiding the public discussion. 

 

From: Ryan Sleevi  
Sent: Friday, December 7, 2018 2:26 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: CA Communication: Underscores in dNSNames

 

 

On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This isn't a CA-issue because the risk associated with non-compliance isn't
defined yet.

 

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

 

""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) 
or remove a certificate at any time and for any reason. This may happen 
immediately or on a planned future date. Mozilla will disable or remove a 
certificate if the CA demonstrates ongoing or egregious practices that do not 
maintain the expected level of service or that do not comply with the 
requirements of this policy.""

 

Sounds like the risk is well-defined and documented.

 

>From what I've heard here, the risk is distrust or loss of EV
indicators, which is distrust-like. That's a pretty big thing to push back
on the CA for a non-security issue.  Thus, I think the risk of missing the
underscore revocation date needs to be discussed here so everyone, including
website operators and the relying parties, know first-hand what the risks of
the CA missing the deadline are. 

 

Any and every qualification or failure to abide by the program requirements 
comes with it the risk of sanction, up to, and including, distrust.

 

It sounds like you're looking for a way for CAs to make a cost/benefit analysis 
as to whether it's more beneficial to them to violate requirements, by having a 
clearer guarantee what it will cost them if they intentionally do so, versus 
what they may gain from their Subscribers. That doesn't really seem aligned 
with the incentives of the ecosystem or the relying parties, since CAs (and 
their Subscribers) are not able to, on purely technical level, evaluate the 
cost or impact to Relying Parties, since Relying Parties include every possible 
entity that trusts that root.

 

If the risk is that there is a note on the
audit, that is an acceptable risk. If the risk is a loss of the
root...probably less so.  Pushing the question back to the CA without better
discussion by the browsers makes finding a solution or understanding the
risks impossible.  

 

While I think it's positive and encouraging to see CAs acknowledge that their 
audits exist to disclose non-conformities/qualifications, I don't think it 
should be seen as legitimizing or accepting that intentional 
non-conformities/qualifications are desirable. A well-run CA should strive to 
have zero qualifications, findings, or non-conformities - not because they were 
able to convince their auditor that they weren't issues / were minor, but 
because they operated above and beyond reproach, and there were literally no 
issues. Anything short of that is an indicator that a CA is failing in its role 
as a trusted steward, and repeated failures seem reasonable to discuss sanction 
or distrust. CAs (and their sub-CAs) with a pattern of incidents on the 
incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and 
https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk 
of sanction, given the pre-existing patterns of non-compliance.



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: CA Communication: Underscores in dNSNames

[Jeremy Rowley via dev-security-policy]

That’s not well defined as there are various grades below that. Is the plan to 
remove any CA that doesn’t comply with this requirement? 

 

From: Ryan Sleevi  
Sent: Friday, December 7, 2018 2:26 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: CA Communication: Underscores in dNSNames

 

 

On Fri, Dec 7, 2018 at 2:00 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

This isn't a CA-issue because the risk associated with non-compliance isn't
defined yet.

 

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

 

""Mozilla MAY, at its sole discretion, decide to disable (partially or fully) 
or remove a certificate at any time and for any reason. This may happen 
immediately or on a planned future date. Mozilla will disable or remove a 
certificate if the CA demonstrates ongoing or egregious practices that do not 
maintain the expected level of service or that do not comply with the 
requirements of this policy.""

 

Sounds like the risk is well-defined and documented.

 

>From what I've heard here, the risk is distrust or loss of EV
indicators, which is distrust-like. That's a pretty big thing to push back
on the CA for a non-security issue.  Thus, I think the risk of missing the
underscore revocation date needs to be discussed here so everyone, including
website operators and the relying parties, know first-hand what the risks of
the CA missing the deadline are. 

 

Any and every qualification or failure to abide by the program requirements 
comes with it the risk of sanction, up to, and including, distrust.

 

It sounds like you're looking for a way for CAs to make a cost/benefit analysis 
as to whether it's more beneficial to them to violate requirements, by having a 
clearer guarantee what it will cost them if they intentionally do so, versus 
what they may gain from their Subscribers. That doesn't really seem aligned 
with the incentives of the ecosystem or the relying parties, since CAs (and 
their Subscribers) are not able to, on purely technical level, evaluate the 
cost or impact to Relying Parties, since Relying Parties include every possible 
entity that trusts that root.

 

If the risk is that there is a note on the
audit, that is an acceptable risk. If the risk is a loss of the
root...probably less so.  Pushing the question back to the CA without better
discussion by the browsers makes finding a solution or understanding the
risks impossible.  

 

While I think it's positive and encouraging to see CAs acknowledge that their 
audits exist to disclose non-conformities/qualifications, I don't think it 
should be seen as legitimizing or accepting that intentional 
non-conformities/qualifications are desirable. A well-run CA should strive to 
have zero qualifications, findings, or non-conformities - not because they were 
able to convince their auditor that they weren't issues / were minor, but 
because they operated above and beyond reproach, and there were literally no 
issues. Anything short of that is an indicator that a CA is failing in its role 
as a trusted steward, and repeated failures seem reasonable to discuss sanction 
or distrust. CAs (and their sub-CAs) with a pattern of incidents on the 
incident dashboard ( https://wiki.mozilla.org/CA/Incident_Dashboard and 
https://wiki.mozilla.org/CA/Closed_Incidents ) probably have the greatest risk 
of sanction, given the pre-existing patterns of non-compliance.



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: AlwaysOnSSL web security issues

[Jeremy Rowley via dev-security-policy]

A couple of thoughts:
1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted 
and operated by DigiCert. All validation, issuance, and linting is performed by 
DigiCert prior to issuance. 
2) Lots of cert customers have insecure websites. This indicates CAs should 
scan websites for vulnerabilities. If that's the case, there will be lots of 
revocations and that needs to be built into the Mozilla policy if required.
3) The only way we know that CertCenter is a reseller is by 
self-identification. They use the same issuance and validation system as all 
other customers. If they didn't self-identify as a reseller, they could do the 
same thing and look like an enterprise. 
4) I think they took their website down once the vulnerability was reported. 
We've asked them to fix the site because it's high profile. However, if the 
customer was something like Mozilla or Google, would we demand revocation of 
their certificates? Granted, they wouldn't have the same vulnerabilities, but 
I'm having a hard time differentiating from the CA perspective. 
5) Generating private keys for third parties is definitely NOT encouraged by 
DigiCert.

Anyway, I'm not sure what do here as it seems like the main difference between 
this and any other insecure website is how they self-identify. 

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, January 10, 2019 7:10 AM
To: Buschart, Rufus 
Cc: Alex Cohn ; 
mozilla-dev-security-pol...@lists.mozilla.org; Hanno Böck 
Subject: Re: AlwaysOnSSL web security issues

The Mozilla policy does not prohibit backdating, except when it's used to evade 
time-based policy controls.

Backdating certs by a few hours is a relatively common practice to minimize 
breakages for consumers with busted clocks.

Alex

On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy < 
dev-security-policy@lists.mozilla.org> wrote:

>  The certificate [1] seems also to be 'back-dated' by about 18 hours. 
> What is Mozillas opinion about this in the light of 
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdat
> ing_the_notBefore_Date
> ?
>
> > It appears AlwaysOnSSL is not completely disabled - if we trust CT 
> > as a
> timestamping service, [1] was issued after Hanno's email.
> [...]
> > [1] https://crt.sh/?id=1097197338
> [...]
> > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > Hi,
> > >
> > > AlwaysOnSSL was a free certificate authority operated by CertCenter.
> > > I recently noticed that their main webpage was gone, but pieces of 
> > > the service were still online.
> > > I immediately found a few web security issues. I reported those to 
> > > certcenter and digicert (which is the root CA their intermediate 
> > > chains to).
> [...]
> > > In response to this the service was completely disabled.
> [...]
> ___
> 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: AlwaysOnSSL web security issues

[Jeremy Rowley via dev-security-policy]

Yes – we will do so. We’ve encouraged all customers to not generate key pairs 
for TLS certs on behalf of third parties in the past. A reminder would be 
useful.

From: Wayne Thayer 
Sent: Thursday, January 10, 2019 1:18 PM
To: Jeremy Rowley 
Cc: Alex Gaynor ; Buschart, Rufus 
; Alex Cohn ; Hanno Böck 
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: AlwaysOnSSL web security issues

Thanks Jeremy. The fact that CertCenter is just a reseller and not an RA was 
not obvious to me. To your point, building an insecure website on top of a CA's 
API does not strike me as something that we should be terribly worried about.

I would encourage DigiCert to ask CertCenter to discontinue the practice of 
generating private keys for their customers.

- Wayne

On Thu, Jan 10, 2019 at 11:00 AM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org>>
 wrote:
A couple of thoughts:
1) CertCenter is not a CA or RA. They have a custom named ICA that is hosted 
and operated by DigiCert. All validation, issuance, and linting is performed by 
DigiCert prior to issuance.
2) Lots of cert customers have insecure websites. This indicates CAs should 
scan websites for vulnerabilities. If that's the case, there will be lots of 
revocations and that needs to be built into the Mozilla policy if required.
3) The only way we know that CertCenter is a reseller is by 
self-identification. They use the same issuance and validation system as all 
other customers. If they didn't self-identify as a reseller, they could do the 
same thing and look like an enterprise.
4) I think they took their website down once the vulnerability was reported. 
We've asked them to fix the site because it's high profile. However, if the 
customer was something like Mozilla or Google, would we demand revocation of 
their certificates? Granted, they wouldn't have the same vulnerabilities, but 
I'm having a hard time differentiating from the CA perspective.
5) Generating private keys for third parties is definitely NOT encouraged by 
DigiCert.

Anyway, I'm not sure what do here as it seems like the main difference between 
this and any other insecure website is how they self-identify.

Jeremy

-Original Message-
From: dev-security-policy 
mailto:dev-security-policy-boun...@lists.mozilla.org>>
 On Behalf Of Alex Gaynor via dev-security-policy
Sent: Thursday, January 10, 2019 7:10 AM
To: Buschart, Rufus 
mailto:rufus.busch...@siemens.com>>
Cc: Alex Cohn mailto:a...@alexcohn.com>>; 
mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org>;
 Hanno Böck mailto:ha...@hboeck.de>>
Subject: Re: AlwaysOnSSL web security issues

The Mozilla policy does not prohibit backdating, except when it's used to evade 
time-based policy controls.

Backdating certs by a few hours is a relatively common practice to minimize 
breakages for consumers with busted clocks.

Alex

On Thu, Jan 10, 2019 at 4:43 AM Buschart, Rufus via dev-security-policy < 
dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

>  The certificate [1] seems also to be 'back-dated' by about 18 hours.
> What is Mozillas opinion about this in the light of
> https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices#Backdat
> ing_the_notBefore_Date
> ?
>
> > It appears AlwaysOnSSL is not completely disabled - if we trust CT
> > as a
> timestamping service, [1] was issued after Hanno's email.
> [...]
> > [1] https://crt.sh/?id=1097197338
> [...]
> > On Wed, Jan 9, 2019 at 8:59 AM Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
>  wrote:
> > >
> > > Hi,
> > >
> > > AlwaysOnSSL was a free certificate authority operated by CertCenter.
> > > I recently noticed that their main webpage was gone, but pieces of
> > > the service were still online.
> > > I immediately found a few web security issues. I reported those to
> > > certcenter and digicert (which is the root CA their intermediate
> > > chains to).
> [...]
> > > In response to this the service was completely disabled.
> [...]
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org<mailto: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<mailto: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<mailto: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: Underscore characters

[Jeremy Rowley via dev-security-policy]

The total number of certs impacted is about 2200. Just more info.

-Original Message-
From: dev-security-policy  On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, December 18, 2018 3:28 PM
To: mozilla-dev-security-policy

Subject: Underscore characters

We're looking at the feasibility of replacing the certificates with
underscore characters by Jan 15th. Revoking all of the certificates will
cause pretty bad outages. We're prepared to revoke them but would like to
discuss (before the date) what should happen if we don't revoke. There are
about 15 customers (which I can't disclose the names yet but am working on
the list of certs). The number of certificates range between 1700-100
certificates per customer. 

 

The primary reason for this is every one of these organization are in a
holiday blackout.  The blackout periods end between Jan 12-Feb 15. Can we
start this discussion now on what this means? I'll provide certificate lists
as I have a timeline on when they plan on replacing.

 

Jeremy

 



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: Underscore characters

[Jeremy Rowley via dev-security-policy]

en had regarding revocation - 
regarding technical non-compliance, compromised keys, weak validation, etc - 
the argument that "replacing a cert is hard" is not really going to be 
acceptable anymore without demonstration about what steps are being taken by 
CAs and Subscribers to mitigate that risk (such as automation) and communicate 
expectations (such as in Subscriber Agreements or Terms of Sale). I don't think 
we want to go through 2019, and certainly not come out of it, having the same 
conversations we've been having in 2018. The best way to prevent that is for 
CAs to take clear steps to work to resolve these issues with their customers, 
so that it never becomes an issue for them, or their CA, in the first place. 
CAs that aren't able to demonstrate steps towards that in future discussions 
are unlikely to be looked upon too favorably if there are future incident 
reports.

 

On Tue, Dec 18, 2018 at 5:43 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

The total number of certs impacted is about 2200. Just more info.

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, December 18, 2018 3:28 PM
To: mozilla-dev-security-policy
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Underscore characters

We're looking at the feasibility of replacing the certificates with
underscore characters by Jan 15th. Revoking all of the certificates will
cause pretty bad outages. We're prepared to revoke them but would like to
discuss (before the date) what should happen if we don't revoke. There are
about 15 customers (which I can't disclose the names yet but am working on
the list of certs). The number of certificates range between 1700-100
certificates per customer. 



The primary reason for this is every one of these organization are in a
holiday blackout.  The blackout periods end between Jan 12-Feb 15. Can we
start this discussion now on what this means? I'll provide certificate lists
as I have a timeline on when they plan on replacing.



Jeremy



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

[Jeremy Rowley via dev-security-policy]

rom the abstract discussion to the 
concrete: imagine you went forward on Jan 15 and had to file an incident 
report. Write the report like that. Include the timeframes, affected 
certificates, impact, root causes, remediation plans, etc. Having a complete 
presentation of what the discussion is about seems critical to having that 
discussion, because it would be unreasonable to expect information to trickle 
in and new customers or use cases added as the discussion progresses.

 

Thus there's a balance to be struck: Treating each hypothetical as a "separate" 
incident report runs the risk of being considered in isolation, ignoring both 
the systemic gaps and the cumulative risk. At the same time, treating it as a 
"singular" incident report tries to paint all problems in the same stroke, and 
can overlook distinct systemic issues. Both cases run the risk of "scope 
creep", which is constantly adding or expanding the scope, which is as well 
received in legitimate incident reports as it is hypothetical (which is to say: 
not well). Perhaps the best analogy is to that of subordinate CAs: each time a 
subordinate has an issue, that's an incident report, and a pattern of issues at 
distinct subordinates is equally a concerning issue for the parent CA. You 
don't want to loop all distinct subordinates into one issue, but you also don't 
want to lose sight of the systemic issues with the parent.

 

Beyond that framing and execution, it seems useful to suggest that any timeline 
about underscores should at least acknowledge Ballot 202 in June 2017 and 
any/all steps the CA took leading up to and following SC12. 

 

None of this is radically new or should be surprising: DigiCert and other CAs 
have already had similar conversations in discussing other matters of BR 
compliance and revocation. All of these have become part of the CA's record of 
incidents. When the CA proposes extending revocation timelines, a discussion of 
the facts, risks, scope, and patterns play a core part in any discussion in 
determining the short term acceptability of the proposal, and unquestionably 
all factor in to any long-term discussions that may later happen.

 

The one last closing thought is that I think we're in the waning days for when 
such hypothetical issues or concrete delay proposals can or should be 
discussed. Given the many discussions that have been had regarding revocation - 
regarding technical non-compliance, compromised keys, weak validation, etc - 
the argument that "replacing a cert is hard" is not really going to be 
acceptable anymore without demonstration about what steps are being taken by 
CAs and Subscribers to mitigate that risk (such as automation) and communicate 
expectations (such as in Subscriber Agreements or Terms of Sale). I don't think 
we want to go through 2019, and certainly not come out of it, having the same 
conversations we've been having in 2018. The best way to prevent that is for 
CAs to take clear steps to work to resolve these issues with their customers, 
so that it never becomes an issue for them, or their CA, in the first place. 
CAs that aren't able to demonstrate steps towards that in future discussions 
are unlikely to be looked upon too favorably if there are future incident 
reports.

 

On Tue, Dec 18, 2018 at 5:43 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

The total number of certs impacted is about 2200. Just more info.

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, December 18, 2018 3:28 PM
To: mozilla-dev-security-policy
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Underscore characters

We're looking at the feasibility of replacing the certificates with
underscore characters by Jan 15th. Revoking all of the certificates will
cause pretty bad outages. We're prepared to revoke them but would like to
discuss (before the date) what should happen if we don't revoke. There are
about 15 customers (which I can't disclose the names yet but am working on
the list of certs). The number of certificates range between 1700-100
certificates per customer. 



The primary reason for this is every one of these organization are in a
holiday blackout.  The blackout periods end between Jan 12-Feb 15. Can we
start this discussion now on what this means? I'll provide certificate lists
as I have a timeline on when they plan on replacing.



Jeremy



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

[Jeremy Rowley via dev-security-policy]

e incident report says. 
In the case of a hypothetical like this, it seems like the hypothetical 
incident report would discuss what is planned or proposed, and should a CA go 
forward with such an intentional violation, the 'actual' incident report would 
equally consider how accurate that was.

 

Recall that the approach to incident reporting is not punitive - it's to make 
sure that we're addressing systemic gaps and issues, that we've understood the 
issues, and have the available data to assess the impact, risk, and any 
patterns of issues. The incident reporting template is one way to provide that 
data in a structured way and to gather feedback.

 

I think a minimum next step is to move from the abstract discussion to the 
concrete: imagine you went forward on Jan 15 and had to file an incident 
report. Write the report like that. Include the timeframes, affected 
certificates, impact, root causes, remediation plans, etc. Having a complete 
presentation of what the discussion is about seems critical to having that 
discussion, because it would be unreasonable to expect information to trickle 
in and new customers or use cases added as the discussion progresses.

 

Thus there's a balance to be struck: Treating each hypothetical as a "separate" 
incident report runs the risk of being considered in isolation, ignoring both 
the systemic gaps and the cumulative risk. At the same time, treating it as a 
"singular" incident report tries to paint all problems in the same stroke, and 
can overlook distinct systemic issues. Both cases run the risk of "scope 
creep", which is constantly adding or expanding the scope, which is as well 
received in legitimate incident reports as it is hypothetical (which is to say: 
not well). Perhaps the best analogy is to that of subordinate CAs: each time a 
subordinate has an issue, that's an incident report, and a pattern of issues at 
distinct subordinates is equally a concerning issue for the parent CA. You 
don't want to loop all distinct subordinates into one issue, but you also don't 
want to lose sight of the systemic issues with the parent.

 

Beyond that framing and execution, it seems useful to suggest that any timeline 
about underscores should at least acknowledge Ballot 202 in June 2017 and 
any/all steps the CA took leading up to and following SC12. 

 

None of this is radically new or should be surprising: DigiCert and other CAs 
have already had similar conversations in discussing other matters of BR 
compliance and revocation. All of these have become part of the CA's record of 
incidents. When the CA proposes extending revocation timelines, a discussion of 
the facts, risks, scope, and patterns play a core part in any discussion in 
determining the short term acceptability of the proposal, and unquestionably 
all factor in to any long-term discussions that may later happen.

 

The one last closing thought is that I think we're in the waning days for when 
such hypothetical issues or concrete delay proposals can or should be 
discussed. Given the many discussions that have been had regarding revocation - 
regarding technical non-compliance, compromised keys, weak validation, etc - 
the argument that "replacing a cert is hard" is not really going to be 
acceptable anymore without demonstration about what steps are being taken by 
CAs and Subscribers to mitigate that risk (such as automation) and communicate 
expectations (such as in Subscriber Agreements or Terms of Sale). I don't think 
we want to go through 2019, and certainly not come out of it, having the same 
conversations we've been having in 2018. The best way to prevent that is for 
CAs to take clear steps to work to resolve these issues with their customers, 
so that it never becomes an issue for them, or their CA, in the first place. 
CAs that aren't able to demonstrate steps towards that in future discussions 
are unlikely to be looked upon too favorably if there are future incident 
reports.

 

On Tue, Dec 18, 2018 at 5:43 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

The total number of certs impacted is about 2200. Just more info.

-----Original Message-----
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Tuesday, December 18, 2018 3:28 PM
To: mozilla-dev-security-policy
mailto:mozilla-dev-security-pol...@lists.mozilla.org> >
Subject: Underscore characters

We're looking at the feasibility of replacing the certificates with
underscore characters by Jan 15th. Revoking all of the certificates will
cause pretty bad outages. We're prepared to revoke them but would like to
discuss (before the date) what should happen if we don't revoke. There are
about 15 customers (which I can't disclose the names yet but am working on
the list of certs). The number of certificates range between 1700-100
ce

RE: DarkMatter Concerns

[Jeremy Rowley via dev-security-policy]

If DarkMatter is issuing from a CA that chains to a Quovadis root trusted by
Mozilla, the issuance is in scope of the Mozilla policy.  But that also
means the cert is publicly trusted. Thus, I read it as "all TLS certs issued
from the public ICA are publicly logged", which matches what Scott told me
in the past. 

You really can't log private certs as they don't chain to a root trusted by
any of the CT logs.

-Original Message-
From: dev-security-policy  On
Behalf Of Buschart, Rufus via dev-security-policy
Sent: Monday, February 25, 2019 1:08 PM
To: mozilla-dev-security-policy

Subject: AW: DarkMatter Concerns

> Von: dev-security-policy 
>  Im Auftrag von Matthew
Hardeman via dev-security-policy On Mon, Feb 25, 2019 at 12:15 PM Richard
Salz  wrote:
> 
> > You miss the point of my question.
> >
> > What types of certs would they issue that would NOT expect to be 
> > trusted by the public?
> I get the question in principle.  If it is a certificate not intended 
> for public trust, I suppose I wonder whether or not it's truly in scope
for policy / browser inclusion / etc discussions?

If the certificate is part of a hierarchy that chains up to a root under
Mozillas Root Program there should be no question about this - yes it is in
scope.

With best regards,
Rufus Buschart

Siemens AG
Information Technology
Human Resources
PKI / Trustcenter
GS IT HR 7 4
Hugo-Junkers-Str. 9
90411 Nuernberg, Germany
Tel.: +49 1522 2894134
mailto:rufus.busch...@siemens.com
www.twitter.com/siemens

www.siemens.com/ingenuityforlife

Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim Hagemann
Snabe; Managing Board: Joe Kaeser, Chairman, President and Chief Executive
Officer; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik
Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin and Munich,
Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich,
HRB 6684; WEEE-Reg.-No. DE 23691322

 

___
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: DarkMatter Concerns

[Jeremy Rowley via dev-security-policy]

Hi all,

Sorry for the delayed response. Been traveling and haven't had a chance to
properly format my thoughts until now. 

As you all know, DigiCert recently acquired the Quovadis CA. As the operator
of the CA, DigiCert is responsible for the issuing CA controlled by
DarkMatter. DarkMatter controls the keys of the intermediate, have their own
CPS, and undergo their own annual audits. 

With one exception, DigiCert has a policy against signing externally
operated intermediate CAs capable of issuing TLS certificates. The exception
is for browser operators who want a cross-sign, which is not applicable in
this case. We've found that limiting external CAs provides a better
situation for users and the security community. As we've done in the past,
we feel there is a logical and legal way to address inherited contracts and
externally operating CAs so that we do not leave site operators and relying
parties using those sites in a lurch. We are committed to working with
DarkMatter on a plan that works for them and aligns to our policy.

As for DarkMatter, we have not received direct evidence of any intentional
mis-issuance or use of a certificate for a MiTM attack. As a policy, we do
not revoke certificates based purely on allegations of wrongdoing.  This is
true regardless of source, such as trademark disputes, government requests
for revocation, and similar matters. We do revoke certificates after
receiving a formal request for revocation from a trust store operator. I
think this policy is a logical approach as the policy avoids government
influence and public pressure over unpopular sites while acknowledging the
browser's control over their root store.

If we are presented with direct evidence of serious BR violations or
wrongdoing, we will certainly act in the best interests of user security and
revoke the intermediate. Wrongdoing warranting revocation definitely
includes using the issuing CA to intercept communication where the
certificate holder does not control the domain.

We already received a formal report on the serial number issue. This issue
reminds me of past discussion
(https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/entr
opy%7Csort:date/mozilla.dev.security.policy/UnR98QjWQQs/Afk5pDHqAQAJ) which
did not warrant removal from the root store. We plan on filling a bug report
on the incident and working with DarkMatter to ensure their systems are
compliant with the BRs. This includes their replacing non-compliant
certificates in accordance with 4.9.1.1. Considering that the certificates
resulted from a misreading of the BRs rather than a malicious act and the
historical precedent in not removing CAs for entropy issues, I don't think
there is justification to revoke the CA. IWe, of course, expect DarkMatter
to update their systems and work with the Mozilla community in providing all
information necessary to resolve concerns about their operation.

Hopefully that answers questions you have.  Feel free to ask me anything.

Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, February 25, 2019 9:53 AM
To: Nick Lamb ; dev-security-policy@lists.mozilla.org
Cc: Kurt Roeckx 
Subject: Re: DarkMatter Concerns

On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote:
> On Sat, 23 Feb 2019 10:16:27 +0100
> Kurt Roeckx via dev-security-policy
>  wrote:
>> I would also like to have a comment from the current root owner
>> (digicert?) on what they plan to do with it.
> 
> Two other things would be interesting from Digicert on this topic
> 
> 1. To what extent does DarkMatter have practical ability to issue 
> independently of Digicert?
> 
> https://crt.sh/?caid=22507
> 
> It would be nice to know where this is on the spectrum of intermediate 
> CAs, between the cPanel intermediate (all day-to-day operations 
> presumably by Sectigo and nobody from cPanel has the associated RSA 
> private keys)

Hi Nick.  I can confirm that all day-to-day operations for the cPanel
intermediates are performed by Sectigo, and nobody from cPanel has the
associated RSA private keys.

> and Let's Encrypt X3 (all day-to-day operations by Let's Encrypt / 
> ISRG and presumably nobody from IdenTrust has the associated RSA 
> private keys)


QuoVadis disclosed [1] that...

"The DarkMatter CAs were previously hosted and operated by QuoVadis, and
included in the QuoVadis WebTrust audits through 2017. In November 2017, the
CAs were transitioned to DarkMatter's own control following disclosure to
browser root programs."

I take that to mean that DarkMatter are in possession of the RSA private key
corresponding to https://crt.sh/?caid=22507.


[1] https://www.quovadisglobal.com/QVRepository/ExternalCAs.aspx

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

RE: DarkMatter Concerns

[Jeremy Rowley via dev-security-policy]

One other thing I wanted to get ahead of is that we are revoking three Dark
Matter issuing CAs tomorrow. This revocation was planned well before this
discussion started. These three certificates were issued in 2016 with
improper name constraints.  The 2017 certificates currently used are
replacements for those certificates without any name constraints. The three
certificates are:

CN=DarkMatter Assured CA,O=DarkMatter LLC,C=AE
4812bd923ca8c43906e7306d2796e6a4cf222e7d2024-04-29 22:53:00
6b6fa65b1bdc2a0f3a7e66b590f93297b8eb56b9
CN=DarkMatter High Assurance CA,O=DarkMatter LLC,C=AE
093c61f38b8bdc7d55df7538020500e125f5c8362024-04-29 22:38:11
8835437d387bbb1b58ff5a0ff8d003d8fe04aed4
CN=DarkMatter Secure CA,O=DarkMatter LLC,C=AE
093c61f38b8bdc7d55df7538020500e125f5c8362024-04-29 22:45:18
6a2c691767c2f1999b8c020cbab44756a99a0c41

Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Jeremy Rowley via dev-security-policy
Sent: Monday, February 25, 2019 1:43 PM
To: Buschart, Rufus ;
mozilla-dev-security-policy 
Subject: RE: DarkMatter Concerns

Hi all,

Sorry for the delayed response. Been traveling and haven't had a chance to
properly format my thoughts until now. 

As you all know, DigiCert recently acquired the Quovadis CA. As the operator
of the CA, DigiCert is responsible for the issuing CA controlled by
DarkMatter. DarkMatter controls the keys of the intermediate, have their own
CPS, and undergo their own annual audits. 

With one exception, DigiCert has a policy against signing externally
operated intermediate CAs capable of issuing TLS certificates. The exception
is for browser operators who want a cross-sign, which is not applicable in
this case. We've found that limiting external CAs provides a better
situation for users and the security community. As we've done in the past,
we feel there is a logical and legal way to address inherited contracts and
externally operating CAs so that we do not leave site operators and relying
parties using those sites in a lurch. We are committed to working with
DarkMatter on a plan that works for them and aligns to our policy.

As for DarkMatter, we have not received direct evidence of any intentional
mis-issuance or use of a certificate for a MiTM attack. As a policy, we do
not revoke certificates based purely on allegations of wrongdoing.  This is
true regardless of source, such as trademark disputes, government requests
for revocation, and similar matters. We do revoke certificates after
receiving a formal request for revocation from a trust store operator. I
think this policy is a logical approach as the policy avoids government
influence and public pressure over unpopular sites while acknowledging the
browser's control over their root store.

If we are presented with direct evidence of serious BR violations or
wrongdoing, we will certainly act in the best interests of user security and
revoke the intermediate. Wrongdoing warranting revocation definitely
includes using the issuing CA to intercept communication where the
certificate holder does not control the domain.

We already received a formal report on the serial number issue. This issue
reminds me of past discussion
(https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/entr
opy%7Csort:date/mozilla.dev.security.policy/UnR98QjWQQs/Afk5pDHqAQAJ) which
did not warrant removal from the root store. We plan on filling a bug report
on the incident and working with DarkMatter to ensure their systems are
compliant with the BRs. This includes their replacing non-compliant
certificates in accordance with 4.9.1.1. Considering that the certificates
resulted from a misreading of the BRs rather than a malicious act and the
historical precedent in not removing CAs for entropy issues, I don't think
there is justification to revoke the CA. IWe, of course, expect DarkMatter
to update their systems and work with the Mozilla community in providing all
information necessary to resolve concerns about their operation.

Hopefully that answers questions you have.  Feel free to ask me anything.

Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Rob Stradling via dev-security-policy
Sent: Monday, February 25, 2019 9:53 AM
To: Nick Lamb ; dev-security-policy@lists.mozilla.org
Cc: Kurt Roeckx 
Subject: Re: DarkMatter Concerns

On 25/02/2019 16:17, Nick Lamb via dev-security-policy wrote:
> On Sat, 23 Feb 2019 10:16:27 +0100
> Kurt Roeckx via dev-security-policy
>  wrote:
>> I would also like to have a comment from the current root owner
>> (digicert?) on what they plan to do with it.
> 
> Two other things would be interesting from Digicert on this topic
> 
> 1. To what extent does DarkMatter have practical ability to issue 
> independently of Digicert?
> 
> https://crt.sh/?caid=22507
> 
> It would be nice to know where this is on the spectrum of intermediate 
> CAs, between the cPanel intermediate 

RE: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Well yes, assuming the validation person overrides the safeguards and randomly 
changes the scope of the domain validation to something other than what the 
system specifies. We're still looking into how this happened and if the 
validation agent did this in any other case. 

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Wednesday, February 27, 2019 8:45 AM
To: dev-security-policy@lists.mozilla.org
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

Okay that seems like an issue as to me that says that this could have happened 
to any domain and not just in-addr.arpa?

- Cynthia

On 2019-02-27 01:55, Jeremy Rowley via dev-security-policy wrote:
>  From our side, a validation agent weirdly scoped the domain, saying that the 
> domain was approved using an email to ad...@in-addr.arpa. However, the email 
> clearly went to ad...@5.168.110.79.in-addr.arpa. We're looking to see 1) how 
> did the validation staff override the domain approval scope and 2) did anyone 
> in validation ever do this before. Once we complete that search, we'll be 
> able to file a bug report and give you more information on what exactly went 
> wrong.
>
> .arpa is in IANA's root zone per https://www.iana.org/domains/root/db.
>
> Jeremy
>
> -Original Message-
> From: dev-security-policy 
>  On Behalf Of Cynthia 
> Revström via dev-security-policy
> Sent: Tuesday, February 26, 2019 4:17 PM
> To: Matthew Hardeman 
> Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
> Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance
>
> I am not so sure that is proper to have .arpa domains in the SANs.
>
> But I think the larger issue I think is that this might allow for non 
> in-addr.arpa domains to be used as well.
>
> It was just that I just tried to get a cert for my domain for a test to see 
> if that would be issued.
>
> And upon verifying the domain via email, I saw that on the page linked in the 
> email it had an option along the lines of "Authorize in-addr.arpa for all 
> orders on account #123456" (not that exact text but the same meaning).
>
> Now I am not sure if this would work, but I suspect if for example I got DNS 
> control over cynthia.site.google.com, I could get a cert for google.com if 
> this is a systemic issue and not just a one off.
>
> - Cynthia
>
> On 2019-02-27 00:10, Matthew Hardeman wrote:
>> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>>
>> While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
>> rarely has anything other than PTR and NS records defined.
>>
>> Here this was clearly achieved by creating a CNAME record for 
>> 69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re>.
>>
>> I've never seen any software or documentation anywhere attempting to 
>> utilize a reverse-IP formatted in-addr.arpa address as though it were 
>> a normal host name for resolution.  I wonder whether this isn't a 
>> case that should just be treated as an invalid domain for purposes of 
>> SAN dnsName (like .local).
>>
>> On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
>> > <mailto:dev-security-policy@lists.mozilla.org>> wrote:
>>
>>  Thanks Cynthia. We are investigating and will report back shortly.
>>  
>>  From: dev-security-policy
>>  >  <mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf
>>  of Cynthia Revström via dev-security-policy
>>  >  <mailto:dev-security-policy@lists.mozilla.org>>
>>  Sent: Tuesday, February 26, 2019 12:02:20 PM
>>  To: dev-security-policy@lists.mozilla.org
>>  <mailto:dev-security-policy@lists.mozilla.org>
>>  Cc: b...@benjojo.co.uk <mailto:b...@benjojo.co.uk>
>>  Subject: Possible DigiCert in-addr.arpa Mis-issuance
>>
>>  Hello dev.security.policy
>>
>>
>>  Apologies if I have made any mistakes in how I post, this is my first
>>  time posting here. Anyway:
>>
>>
>>  I have managed to issue a certificate with a FQDN in the SAN that I do
>>  not have control of via Digicert.
>>
>>
>>  The precert is here: https://crt.sh/?id=1231411316
>>
>>  SHA256:
>>  651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1
>>
>>
>>  I have notified Digicert who responded back with a generic response
>>  followed by the certificate being revoked through OCSP. However I
>>  believe that this should be wider investigated, since this cert was

RE: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Thanks Wayne

 

From: Wayne Thayer  
Sent: Friday, March 1, 2019 10:00 AM
To: Jeremy Rowley 
Cc: mozilla-dev-security-policy 
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

 

https://bugzilla.mozilla.org/show_bug.cgi?id=1531817 has been created to track 
this issue.

 

On Wed, Feb 27, 2019 at 10:52 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hi Cynthia, 

We've figured out what happened with your certificate but are still looking at 
whether other certificates were issued using the same process. I don't have 
enough information to file an incident report yet, but I wanted to give you the 
update I promised earlier. 

Basically, here's what happened:
1. A validation agent took an email address provided during a chat session with 
you and set that email as a WHOIS admin email address. This email qualified as 
a constructed email (admin@domain)
2. The system marked the WHOIS as unavailable for automated parsing (generally, 
this happens if we are being throttled or the WHOIS info is behind a CAPTCHA), 
which allows a validation agent to manually upload a WHOIS document
3. The WHOIS document uploaded was a screen capture of WHOIS information that 
did not match the domain being requested but was close enough that the 
mis-match went unnoticed. 
4. The validation agent specified the approval scope as id-addr.arpa which is 
normal for a domain approved by the admin listed in WHOIS. As a constructed 
email, the approval scope should have been limited to the scope set by the 
constructed address.
5. The validation agent specified that the email address listed in WHOIS 
matched the email address provided by you (admin@domain) and sent the email to 
authorize the legit cert
6 . When the validation completed successfully, the validation authorized your 
account for all certificates with the in-addr.arpa domain. This was because the 
scope was improperly set based on the validation agent's improper specification 
of the source of the email address. 
7. During the review, no one noticed that the WHOIS document did not match the 
verification email nor did anyone notice that the email used for verification 
was actually a constructed email instead of the WHOIS admin email.
8. The mis-issued certificate essentially "piggy-backed" on the previous 
verification because of the erroneous approval scope set by the validation 
staff.

Make sense? 

We shut down manual WHOIS verification while we figure out how to improve the 
process and eliminate validation mistakes like this. We'll post another update 
after we figure out how to improve the process and after the data review is 
complete.

Jeremy

-Original Message-
From: dev-security-policy mailto:dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Cynthia 
Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 4:17 PM
To: Matthew Hardeman mailto:mharde...@gmail.com> >
Cc: dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> ; b...@benjojo.co.uk 
<mailto:b...@benjojo.co.uk> 
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.

It was just that I just tried to get a cert for my domain for a test to see if 
that would be issued.

And upon verifying the domain via email, I saw that on the page linked in the 
email it had an option along the lines of "Authorize in-addr.arpa for all 
orders on account #123456" (not that exact text but the same meaning).

Now I am not sure if this would work, but I suspect if for example I got DNS 
control over cynthia.site.google.com <http://cynthia.site.google.com> , I could 
get a cert for google.com <http://google.com>  if this is a systemic issue and 
not just a one off.

- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:
> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>
> While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
> rarely has anything other than PTR and NS records defined.
>
> Here this was clearly achieved by creating a CNAME record for 
> 69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re>  
> <http://cynthia.re>.
>
> I've never seen any software or documentation anywhere attempting to 
> utilize a reverse-IP formatted in-addr.arpa address as though it were 
> a normal host name for resolution.  I wonder whether this isn't a case 
> that should just be treated as an invalid domain for purposes of SAN 
> dnsName (like .local).
>
> On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
>  <mailto:dev-security-policy@lists.mozilla.org> 
> <mailto:dev-security-policy@lists.mozilla.

RE: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Technically, the same issue could exist on the system. However, co.uk is
actually blocked as a valid approval address by our system. In-addr.arpa was
not blocked. 

Here's a status update:
1) We identified 3000 certificates where the scope was changed by validation
staff based on a WHOIS document. 
2) Of the 3,000, the only certificate we found where the scope was not set
to be the scope of the WHOIS document was the one reported by Cynthia. 

The next step is to look at why we didn't block in-addr.arpa as an eligible
scope. We generally pull from the PSL, so I need to find out why
in-addr.arpa was not blocked.

Thanks!
Jeremy

-Original Message-
From: dev-security-policy  On
Behalf Of Cynthia Revström via dev-security-policy
Sent: Saturday, March 2, 2019 1:46 AM
To: George Macon 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

On 2019-03-02 01:49, George Macon via dev-security-policy wrote:

> One specific question on this point: Why did the software permit 
> setting the approval scope to a public suffix (as defined by inclusion 
> on the public suffix list)? Could validation agent action set the 
> approval scope to some other two-label public suffix like co.uk?

I think this is highly unlikely seeing as this was a human error and unlike
in-addr.arpa, people might know about .co.uk.

- Cynthia

___
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: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Thanks Cynthia. We are investigating and will report back shortly.

From: dev-security-policy  on 
behalf of Cynthia Revström via dev-security-policy 

Sent: Tuesday, February 26, 2019 12:02:20 PM
To: dev-security-policy@lists.mozilla.org
Cc: b...@benjojo.co.uk
Subject: Possible DigiCert in-addr.arpa Mis-issuance

Hello dev.security.policy


Apologies if I have made any mistakes in how I post, this is my first
time posting here. Anyway:


I have managed to issue a certificate with a FQDN in the SAN that I do
not have control of via Digicert.


The precert is here: https://crt.sh/?id=1231411316

SHA256: 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1


I have notified Digicert who responded back with a generic response
followed by the certificate being revoked through OCSP. However I
believe that this should be wider investigated, since this cert was
issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
that I do control though reverse DNS.


When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
that the whole of in-addr.arpa became validated on my account, instead
of just my small section of it (168.110.79.in-addr.arpa at best).


To test if digicert had just in fact mis-validated a FQDN, I tested with
the reverse DNS address of 192.168.1.1, and it worked and Digicert
issued me a certificate with 1.1.168.192.in-addr.arpa on it.


Is there anything else dev.security.policy needs to do with this? This
seems like a clear case of mis issuance. It's also not clear if
in-addr.arpa should even be issuable.


I would like to take a moment to thank Ben Cartwright-Cox and igloo5
in pointing out this violation.


Regards

Cynthia Revström

___
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 DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

>From our side, a validation agent weirdly scoped the domain, saying that the 
>domain was approved using an email to ad...@in-addr.arpa. However, the email 
>clearly went to ad...@5.168.110.79.in-addr.arpa. We're looking to see 1) how 
>did the validation staff override the domain approval scope and 2) did anyone 
>in validation ever do this before. Once we complete that search, we'll be able 
>to file a bug report and give you more information on what exactly went wrong. 

.arpa is in IANA's root zone per https://www.iana.org/domains/root/db.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 4:17 PM
To: Matthew Hardeman 
Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.

It was just that I just tried to get a cert for my domain for a test to see if 
that would be issued.

And upon verifying the domain via email, I saw that on the page linked in the 
email it had an option along the lines of "Authorize in-addr.arpa for all 
orders on account #123456" (not that exact text but the same meaning).

Now I am not sure if this would work, but I suspect if for example I got DNS 
control over cynthia.site.google.com, I could get a cert for google.com if this 
is a systemic issue and not just a one off.

- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:
> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>
> While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
> rarely has anything other than PTR and NS records defined.
>
> Here this was clearly achieved by creating a CNAME record for 
> 69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re>.
>
> I've never seen any software or documentation anywhere attempting to 
> utilize a reverse-IP formatted in-addr.arpa address as though it were 
> a normal host name for resolution.  I wonder whether this isn't a case 
> that should just be treated as an invalid domain for purposes of SAN 
> dnsName (like .local).
>
> On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
>  <mailto:dev-security-policy@lists.mozilla.org>> wrote:
>
> Thanks Cynthia. We are investigating and will report back shortly.
> 
> From: dev-security-policy
>  <mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf
> of Cynthia Revström via dev-security-policy
>  <mailto:dev-security-policy@lists.mozilla.org>>
> Sent: Tuesday, February 26, 2019 12:02:20 PM
> To: dev-security-policy@lists.mozilla.org
> <mailto:dev-security-policy@lists.mozilla.org>
> Cc: b...@benjojo.co.uk <mailto:b...@benjojo.co.uk>
> Subject: Possible DigiCert in-addr.arpa Mis-issuance
>
> Hello dev.security.policy
>
>
> Apologies if I have made any mistakes in how I post, this is my first
> time posting here. Anyway:
>
>
> I have managed to issue a certificate with a FQDN in the SAN that I do
> not have control of via Digicert.
>
>
> The precert is here: https://crt.sh/?id=1231411316
>
> SHA256:
> 651B68C520492A44A5E99A1D6C99099573E8B53DEDBC69166F60685863B390D1
>
>
> I have notified Digicert who responded back with a generic response
> followed by the certificate being revoked through OCSP. However I
> believe that this should be wider investigated, since this cert was
> issued by me adding 69.168.110.79.in-addr.arpa to my SAN, a DNS area
> that I do control though reverse DNS.
>
>
> When I verified 5.168.110.79.in-addr.arpa (same subdomain), I noticed
> that the whole of in-addr.arpa became validated on my account, instead
> of just my small section of it (168.110.79.in-addr.arpa at best).
>
>
> To test if digicert had just in fact mis-validated a FQDN, I
> tested with
> the reverse DNS address of 192.168.1.1, and it worked and Digicert
> issued me a certificate with 1.1.168.192.in-addr.arpa on it.
>
>
> Is there anything else dev.security.policy needs to do with this? This
> seems like a clear case of mis issuance. It's also not clear if
> in-addr.arpa should even be issuable.
>
>
> I would like to take a moment to thank Ben Cartwright-Cox and
> igloo5
> in pointing out this violation.
>
>
> Regards
>
> Cynthia Revström
>
> ___
> dev-security-policy mailing list

RE: Possible DigiCert in-addr.arpa Mis-issuance

[Jeremy Rowley via dev-security-policy]

Hi Cynthia, 

We've figured out what happened with your certificate but are still looking at 
whether other certificates were issued using the same process. I don't have 
enough information to file an incident report yet, but I wanted to give you the 
update I promised earlier. 

Basically, here's what happened:
1. A validation agent took an email address provided during a chat session with 
you and set that email as a WHOIS admin email address. This email qualified as 
a constructed email (admin@domain)
2. The system marked the WHOIS as unavailable for automated parsing (generally, 
this happens if we are being throttled or the WHOIS info is behind a CAPTCHA), 
which allows a validation agent to manually upload a WHOIS document
3. The WHOIS document uploaded was a screen capture of WHOIS information that 
did not match the domain being requested but was close enough that the 
mis-match went unnoticed. 
4. The validation agent specified the approval scope as id-addr.arpa which is 
normal for a domain approved by the admin listed in WHOIS. As a constructed 
email, the approval scope should have been limited to the scope set by the 
constructed address.
5. The validation agent specified that the email address listed in WHOIS 
matched the email address provided by you (admin@domain) and sent the email to 
authorize the legit cert
6 . When the validation completed successfully, the validation authorized your 
account for all certificates with the in-addr.arpa domain. This was because the 
scope was improperly set based on the validation agent's improper specification 
of the source of the email address. 
7. During the review, no one noticed that the WHOIS document did not match the 
verification email nor did anyone notice that the email used for verification 
was actually a constructed email instead of the WHOIS admin email.
8. The mis-issued certificate essentially "piggy-backed" on the previous 
verification because of the erroneous approval scope set by the validation 
staff.

Make sense? 

We shut down manual WHOIS verification while we figure out how to improve the 
process and eliminate validation mistakes like this. We'll post another update 
after we figure out how to improve the process and after the data review is 
complete.

Jeremy

-Original Message-
From: dev-security-policy  On 
Behalf Of Cynthia Revström via dev-security-policy
Sent: Tuesday, February 26, 2019 4:17 PM
To: Matthew Hardeman 
Cc: dev-security-policy@lists.mozilla.org; b...@benjojo.co.uk
Subject: Re: Possible DigiCert in-addr.arpa Mis-issuance

I am not so sure that is proper to have .arpa domains in the SANs.

But I think the larger issue I think is that this might allow for non 
in-addr.arpa domains to be used as well.

It was just that I just tried to get a cert for my domain for a test to see if 
that would be issued.

And upon verifying the domain via email, I saw that on the page linked in the 
email it had an option along the lines of "Authorize in-addr.arpa for all 
orders on account #123456" (not that exact text but the same meaning).

Now I am not sure if this would work, but I suspect if for example I got DNS 
control over cynthia.site.google.com, I could get a cert for google.com if this 
is a systemic issue and not just a one off.

- Cynthia

On 2019-02-27 00:10, Matthew Hardeman wrote:
> Is it even proper to have a SAN dnsName in in-addr.arpa ever?
>
> While in-addr.arpa IS a real DNS heirarchy under the .arpa TLD, it 
> rarely has anything other than PTR and NS records defined.
>
> Here this was clearly achieved by creating a CNAME record for 
> 69.168.110.79.in-addr.arpa pointed to cynthia.re <http://cynthia.re>.
>
> I've never seen any software or documentation anywhere attempting to 
> utilize a reverse-IP formatted in-addr.arpa address as though it were 
> a normal host name for resolution.  I wonder whether this isn't a case 
> that should just be treated as an invalid domain for purposes of SAN 
> dnsName (like .local).
>
> On Tue, Feb 26, 2019 at 1:05 PM Jeremy Rowley via dev-security-policy 
>  <mailto:dev-security-policy@lists.mozilla.org>> wrote:
>
> Thanks Cynthia. We are investigating and will report back shortly.
> 
> From: dev-security-policy
>  <mailto:dev-security-policy-boun...@lists.mozilla.org>> on behalf
> of Cynthia Revström via dev-security-policy
>  <mailto:dev-security-policy@lists.mozilla.org>>
> Sent: Tuesday, February 26, 2019 12:02:20 PM
> To: dev-security-policy@lists.mozilla.org
> <mailto:dev-security-policy@lists.mozilla.org>
> Cc: b...@benjojo.co.uk <mailto:b...@benjojo.co.uk>
> Subject: Possible DigiCert in-addr.arpa Mis-issuance
>
> Hello dev.security.policy
>
>
> Apologies if I have made any mistakes in how I post, this 

RE: Pre-Incident Report - GoDaddy Serial Number Entropy

[Jeremy Rowley via dev-security-policy]

No one wants to paint a target on their back. If I announce we're 100%
compliant with everything, that's asking to be shot in the face. You're
welcome to look at ours. I think we fully comply with 7.1 (I've double
checked everything) and would love to find out if we're not. I like the
feedback and research so feel free to peel away at the DigiCert parfait. 

-Original Message-
From: dev-security-policy  On
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Wednesday, March 13, 2019 8:03 PM
To: Peter Gutmann 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Richard Moore

Subject: Re: Pre-Incident Report - GoDaddy Serial Number Entropy

On Wed, Mar 13, 2019 at 6:09 PM Peter Gutmann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Richard Moore via dev-security-policy < 
> dev-security-policy@lists.mozilla.org> writes:
>
> >If any other CA wants to check theirs before someone else does, then 
> >now
> is
> >surely the time to speak up.
>
> I'd already asked previously whether any CA wanted to indicate 
> publicly that they were compliant with BR 7.1, which zero CAs 
> responded to (I counted them twice).  This means either there are very 
> few CAs bothering with
> dev-security-
> policy, or they're all hunkering down and hoping it'll blow over, 
> which given that they're going to be forced to potentially carry out 
> mass revocations would be the game-theoretically sensible approach to 
> take:


To be fair, this is not an either/or proposition. The third option is that
they could be ignoring you specifically, which may not be an unreasonable
position, game-theoretically speaking of course.
___
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: Pre-Incident Report - GoDaddy Serial Number Entropy

[Jeremy Rowley via dev-security-policy]

If they need some help with large scale replacement, I know some people who did 
that recently . Joking of course, but really - with Godaddy, Google, and Apple 
reporting a large number of certs that have what seems to be a minor compliance 
issue in light of the certs all being SHA2, does Mozilla want to require a 
complete revocation and replacement? Seems like a lot of effort and disruption 
for little value to the Mozilla community.


-Original Message-
From: dev-security-policy  On 
Behalf Of okaphone.elektronika--- via dev-security-policy
Sent: Friday, March 8, 2019 12:28 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Pre-Incident Report - GoDaddy Serial Number Entropy

On Friday, 8 March 2019 17:07:57 UTC+1, Wayne Thayer  wrote:
> I've created https://bugzilla.mozilla.org/show_bug.cgi?id=1533774 to 
> track this issue.
> 
> Apple has also submitted the following bug for this issue listing a 
> large number of impacted certificates:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1533655
> 
> - Wayne

Wow! Looks like there are going to be A LOT of certificates that MUST be 
revoked. Formally correct of course, but could it perhaps be a good idea to 
consider the possibility of handling this one somewhat different? ;-)

CU Hans
___
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: Pre-Incident Report - GoDaddy Serial Number Entropy

[Jeremy Rowley via dev-security-policy]

Apologies, I realize that Mozilla’s policy is that revocation is up to the CA 
and there is no such thing as an exception. A more careful way to state what I 
meant is that I’m surprised that there is not more discussion around the 
revocation of all of these certificates and the impact to the ecosystem 
compared to an assumption that they will all be revoked. There has been some 
discussion of course, but 1.8 million certificates is a lot of certificates to 
replace. I’d think to see more discussion here from GoDaddy about ether they 
are replacing the certificates or not and the pros and cons of doing so.

 

From: Wayne Thayer  
Sent: Friday, March 8, 2019 3:46 PM
To: Ryan Sleevi 
Cc: Jeremy Rowley ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Pre-Incident Report - GoDaddy Serial Number Entropy

 

Ryan beat me to the punch. so I'll reinforce his message with my own:

 

The overall potential impact from revocations in the current scenario feels 
quite similar to the potential for disruption from revoking certificates 
containing underscores a few months ago. Mozilla's guidance for revocation [1] 
was updated based on the "underscores" discussion, and it is generally 
applicable here. (I will give it another review in light of the current 
situation.)

 

In my opinion, Mozilla should not get in to the business of granting one-off 
exceptions to the BR revocation requirements. In this case, doing so would 
certainly not be fair to Google, and in the future would only result in 
constant pleas for mercy that would be near impossible to refuse. Revocation 
decisions should ultimately be made by CAs and followed up with disclosure and 
preventative action. Mozilla should highlight situations where delaying 
revocation will be viewed as an egregious failure by a CA to respond to an 
imminent threat.

 

I believe that Google's response here sets a good, if imperfect, example of the 
agility we desire for the entire web PKI. I hope that the current event serves 
to illustrate the need for agility and encourages CAs to develop more solutions 
that move us in that direction.

 

- Wayne

 

[1] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation

 

On Fri, Mar 8, 2019 at 3:40 PM Ryan Sleevi via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

On Fri, Mar 8, 2019 at 4:35 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

> does Mozilla want to require a complete revocation and replacement? Seems
> like a lot of effort and disruption for little value to the Mozilla
> community.


I'm surprised, given the length of the discussion in [1], to see such an
unhelpful framing of the issue, as it sounds remarkably like asking for an
"exception". I had hoped that the changes [2] to the policy [3] had
provided greater clarity about what the expectations are for CAs. It does
seem that CAs are following that process, which is something another CA
recently did in the case of underscores, so perhaps its best to not try and
re-open that discussion? :)

I think a particular piece of guidance and clarification, expected of such
incident reports, and captured in [3], is
"That you will perform an analysis to determine the factors that prevented
timely revocation of the certificates, and include a set of remediation
actions in the final incident report that aim to prevent future revocation
delays."

It does seem that this is an essential and valuable piece for the
community, regardless of the CA affected and regardless of the nature of
the incident. After all, it doesn't seem to dissimilar to the discussion
regarding Heartbleed, and the challenges the ecosystem faced then.

[1]
https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/pnywuWbmBwAJ
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/HdirGOy6TJI/oIHKXeSuCAAJ
[3] https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto: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: GoDaddy Revocation Disclosure

[Jeremy Rowley via dev-security-policy]

One item that I think could bear a useful discussion from these incident 
reports is how the community can get more involved in discussing and helping 
with incident reports. For example, the 63 bit serial number issue is leading 
to a lot of certs potentially being revoked with little benefit to the 
community (IMO of course). There are definite downsides to revocation that may 
or may not be fully considered when people are responding to incidents. For 
example, adding a bunch of certs to a CRL for a minor issue seems like a 
pointless increase in CRL size. There's also the customer disruption and other 
issues to consider that are probably important for the community to know when 
looking at incident reports.  

I'm wondering if we (the community or CABForum) should have some mechanism of 
evaluating these risks and  proposed incident plans before/while the plan is 
executed. For example, the pros and cons of revocation of the certs could be 
discussed. Actual revocation would be up to the CA , course, and any 
non-compliances would be noted on the audit report, but this part of the policy 
could be a community effort: "That you will perform an analysis to determine 
the factors that prevented timely revocation of the certificates, and include a 
set of remediation actions in the final incident report that aim to prevent 
future revocation delays." 
(https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation). We could 
have the CA propose a rough draft to the community where they engage in a QA 
about the incident and then have members make a recommendation to the CA about 
remediation. All voluntary on the advice. This is probably the way it is 
supposed to currently work, but right now the  flow seems like:
1) Post to Mozilla
2) Create an incident report
3) Community discussion about compliance and why CAs need to do better 
4) Update incident report until Wayne closes it

A new flow that includes the community more fully could be:
1) Post to Mozilla, the post must include an initial proposed plan of action
2) Create an incident report (to track bugs)
3) Discuss on the Mozilla forum the proposed plan and post updated plans based 
on member suggestions
4) Post a final draft to Bugzilla
5) Post updates per a timeline set in the incident report
6) Wayne closes the bug.

This is probably a lot more work for the CA, but I know we'd find the community 
feedback on how to resolve issues useful. Maybe it could also change into a 
continuous flow of "How can X CA do better - here's some suggestions" instead 
of "Better put up the lightning rod and get through this". 

Thoughts? Again, probably how this is supposed to work already, but if we can 
turn it into more actionable feedback about what's next, then I'd find that 
super useful. 

Jeremy

 

-Original Message-
From: dev-security-policy  On 
Behalf Of Daymion Reynolds via dev-security-policy
Sent: Monday, August 20, 2018 10:27 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: GoDaddy Revocation Disclosure

On Saturday, August 18, 2018 at 2:27:05 PM UTC-7, Ben Laurie wrote:
> On Fri, 17 Aug 2018 at 18:22, Daymion Reynolds via dev-security-policy 
> < dev-security-policy@lists.mozilla.org> wrote:
> 
> > Revoke Disclosure
> >
> > GoDaddy has been proactively performing self-audits. As part of this 
> > process, we identified a vulnerability in our code that would allow 
> > our validation controls to be bypassed. This bug would allow for a 
> > Random Value that was generated for intended use with Method 
> > 3.2.2.4.6 and 3.2.2.4.7 and was validated using Method 3.2.2.4.2 by 
> > persons who were not confirmed as the domain contact. This bug was 
> > introduced November 2014 and was leveraged to issue a total of 865 
> > certificates. The bug was closed hours after identification, and in 
> > parallel we started the scope and revocation activities.
> >
> > In accordance with CA/B Forum BR, section 4.9.1.1, all miss-issued 
> > certificates were revoked within 24 hours of identification.
> >
> > A timeline of the Events for Revocation are as follows:
> >
> > 8/13 9:30am – Exploit issue surfaced as possible revocation event.
> > 8/13 9:30-4pm – Issue scope identification (at this point it was 
> > unknown), gathering certificate list
> > 8/13 4pm – Certificate list finalized for revoke total 825 certs, 
> > Revoke notification sent to cert owners.
> >
> 
> I presume you mean domain owners?
> 
> Do we know if any of these certs were used? If so, how?
> 
> 
> > 8/14 1:30pm – All certificates revoked.
> >
> > Further research identified 40 certificates which contained re-use 
> > of suspect validation information.
> > 8/15 – 2pm – Additional certificates identified due to re-use.
> > 8/15 – 2:30pm – Customers notified of pending revoke.
> > 8/16 – 12:30pm – All certificated revoked.
> >
> > We stand ready to answer any questions or concerns.
> > Daymion
> >

Yes, domain owners.

Yes, some of the certs were being used as typical 

RE: GoDaddy Revocation Disclosure

[Jeremy Rowley via dev-security-policy]

Not looking for blanket approval – I stated it’d still be part of the audit 
report. We also aren’t directly impacted by this particular incident (which is 
why I brought it up here). The actual evaluation of the CA would remain up to 
Mozilla of course, but the really good discussion about 63 bits (especially the 
proposed ballot language) got me thinking about how we could apply this more 
generally to incident reports and how CAs can use them before deciding on a 
course of action. The underscore discussion was definitely good as well, and I 
felt had a great outcome.

 

I think the primary change I’m proposing is that the initial report shouldn’t 
be an incident report. Instead, the initial report can be short blurb posted to 
Mozilla along with a description on what the Ca plans to do. Then the community 
can talk about the plan in addition to the incident, rather than just the 
incident. 

 

Jeremy

 

From: Ryan Sleevi  
Sent: Tuesday, March 12, 2019 2:31 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: GoDaddy Revocation Disclosure

 

 

 

On Tue, Mar 12, 2019 at 4:17 PM Jeremy Rowley via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

A new flow that includes the community more fully could be:
1) Post to Mozilla, the post must include an initial proposed plan of action
2) Create an incident report (to track bugs)
3) Discuss on the Mozilla forum the proposed plan and post updated plans based 
on member suggestions
4) Post a final draft to Bugzilla
5) Post updates per a timeline set in the incident report
6) Wayne closes the bug.

This is probably a lot more work for the CA, but I know we'd find the community 
feedback on how to resolve issues useful. Maybe it could also change into a 
continuous flow of "How can X CA do better - here's some suggestions" instead 
of "Better put up the lightning rod and get through this". 

 

So, I think many of these elements are already captured in the current process, 
as the lengthy discussion with DigiCert regarding underscores [1], and this 
provides a model for engaging with the community and gathering feedback and 
concerns about the response.

 

CAs are responsible for drafting their initial incident reports, gathering 
feedback, and making a decision - much as DigiCert did with underscores. The CA 
is judged based on how well they considered and balanced the risks, there is 
opportunity for concerns about improving (an area DigiCert encountered with its 
own reports), and we move forward.

 

It would seem, from your broader message, that this is looking for some sort of 
blanket approval, independent of the CA or facts specific to that CA, and I 
think that's something that we've been explicitly trying to avoid - as the 
context matters. There are a number of hazards, which Matt Palmer highlighted 
during the discussion of underscores [2][3][4], and I think those still apply 
now as much as they did two and a half months ago.

 

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/pnywuWbmBwAJ
 

[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/APSWO4SYCgAJ

[3] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/voFCTMFVAwAJ

[4] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/0oy4uTEVnus/ZqO9fHZMAwAJ



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]

[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]

[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

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

[Jeremy Rowley via dev-security-policy]

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 

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 
<mailto: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'