Re: Action on undisclosed intermediates

Hi Gerv, Is it your intent that once OneCRL-revoked intermediates are brought into compliance that they'd be removed from OneCRL, or are they gone for good, a warning sign to those who follow. Alex PS: Maybe it'd be good to use a source of randomness that is not from the UK government. On

Re: Implementing a SHA-1 ban via Mozilla policy

On 08/11/16 13:44, Doug Beattie wrote: > GlobalSign generated some SHA-1 CAs earlier this year as part of > normal CA lifecycle management. Hi Doug, This is helpful information - can you post it to the bug? https://bugzilla.mozilla.org/show_bug.cgi?id=1315018 > Why did we not technically

Action on undisclosed intermediates

Hi everyone, I'd like to take some action about persistent failures to properly disclose intermediates. The deadline for this was June, and CAs have had a number of reminders, so there's no excuse. Of course, if intermediates aren't disclosed, we can't be certain what they are, but crt.sh has a

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 2:05 AM, Gervase Markham wrote: > On 07/11/16 17:25, Ryan Sleevi wrote: >> Yes. An 'evil log' can provide a divided split-view, targeting only >> an affected number of users. Unless that SCT was observed, and >> reported (via Gossip or some other means of

Re: Implementing a SHA-1 ban via Mozilla policy

On Tue, 8 Nov 2016 11:17:29 + Gervase Markham wrote: > On 07/11/16 17:09, Nick Lamb wrote: > > On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote: > >> You mean EKU-constrained (e.g. to email, or OCSP only)? > > > > I was thinking also of a pathlen constraint.

Re: Action on undisclosed intermediates

On 08/11/16 16:28, alex.gay...@gmail.com wrote: > Is it your intent that once OneCRL-revoked intermediates are brought > into compliance that they'd be removed from OneCRL, or are they gone > for good, a warning sign to those who follow. TBD. I'm enquiring about whether it's possible to remove

Re: Action on undisclosed intermediates

On 08/11/16 16:47, Kurt Roeckx wrote: > We also need to have a sorted list of them. I guess the list of crt.sh > is acceptable. Sorting could for instance been done by sorting based on > the SHA256. I was planning to take the list in the order given by crt.sh at 2pm each Monday, yes. Gerv

Re: Action on undisclosed intermediates

On Tue, Nov 8, 2016 at 10:17 AM, Gervase Markham wrote: > Hi Peter, > > On 08/11/16 16:53, Peter Bowen wrote: >> Can the "undisclosed" list be broken down further into "CA not >> disclosed at all" versus "missing disclosure of some >> cross-certificate"? >> >> For example,

Re: Action on undisclosed intermediates

On Tue, Nov 8, 2016 at 11:05 AM, Gervase Markham wrote: > On 08/11/16 18:25, Peter Bowen wrote: >> No, the problem is that the Issuer reported their subCA but Salesforce >> links the audit info to certificates not to CAs. In the above >> example, there are three different CA

Re: Action on undisclosed intermediates

On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham wrote: > Of course, if intermediates aren't disclosed, we can't be certain what > they are, but crt.sh has a good idea of many of them: > https://crt.sh/mozilla-disclosures#undisclosed > > There is also a list on that page of certs

Re: Action on undisclosed intermediates

On 08/11/2016 19:08, Gervase Markham wrote: On 08/11/16 16:28, alex.gay...@gmail.com wrote: Is it your intent that once OneCRL-revoked intermediates are brought into compliance that they'd be removed from OneCRL, or are they gone for good, a warning sign to those who follow. TBD. I'm

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 12:53 AM, Kurt Roeckx wrote: > On 2016-11-07 18:25, Ryan Sleevi wrote: >> >> This is why it's vitally important that clients fetch inclusion proofs in >> some manner > > > Have you considered a TLS extension, have the server fetch them and send to > the

Re: Action on undisclosed intermediates

Hi Peter, On 08/11/16 16:53, Peter Bowen wrote: > Can the "undisclosed" list be broken down further into "CA not > disclosed at all" versus "missing disclosure of some > cross-certificate"? > > For example, ACCVCA-130 is listed under both "Disclosed" and > "Unconstrained id-kp-serverAuth Trust".

Re: Action on undisclosed intermediates

On 08/11/16 18:25, Peter Bowen wrote: > No, the problem is that the Issuer reported their subCA but Salesforce > links the audit info to certificates not to CAs. In the above > example, there are three different CA certificates with the same > issuer and subject, so the same (sub)CA is in both a

Re: Mozilla CT Policy

On 08/11/2016 17:50, Ryan Sleevi wrote: On Tue, Nov 8, 2016 at 2:05 AM, Gervase Markham wrote: ... ... Presumably this is one reason some people are suggesting Mozilla's policy have a jurisdictional diversity requirement - to make such coercion harder. Possibly, but I

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 11:24 AM, Jakob Bohm wrote: > Diversity requirements are about reducing the likelihood of > simultaneous coercion, as it can never be ruled out that some powerful > organization already engaged in such things could use some of its > backhanded tactics

Re: Mozilla CT Policy

On 08/11/2016 20:51, Ryan Sleevi wrote: On Tue, Nov 8, 2016 at 11:24 AM, Jakob Bohm wrote: Diversity requirements are about reducing the likelihood of simultaneous coercion, as it can never be ruled out that some powerful organization already engaged in such things could

Re: Action on undisclosed intermediates

On 08/11/16 16:18, Gervase Markham wrote: > We would choose 3 certs from the list as it exists every Monday at 2pm > UK time, using the following sources of randomness for the algorithm: > > 1) UK National Lottery "Lotto" numbers, not including bonus ball > 2) UK National Lottery "Thunderball"

Re: Action on undisclosed intermediates

On Tuesday, November 8, 2016 at 8:19:15 AM UTC-8, Gervase Markham wrote: > Hi everyone, > > I'd like to take some action about persistent failures to properly > disclose intermediates. The deadline for this was June, and CAs have had > a number of reminders, so there's no excuse. I've been

Re: Action on undisclosed intermediates

On 08/11/16 19:08, Peter Bowen wrote: > Yes, that is how one fixes it. But I'm worried that CAs may think > they properly followed the requirement and then find themselves > penalized. Hence my suggestion to focus on CAs that clearly have not > even attempted to follow the requirement. For

Re: Action on undisclosed intermediates

On 08/11/16 19:11, Jakob Bohm wrote: > However because all the sources are from a single entity (the UK > government), that entity could manipulate the results, thus falsifying > the provable randomness of the process. I think you are bikeshedding the wrong part of this process. The draws are

Re: Mozilla CT Policy

On Tue, Nov 8, 2016 at 12:07 PM, Jakob Bohm wrote: > I was responding to your simplistic argument that the existence of > ownership change detection failures made diversity requirements > worthless. I was not calculating their actual worth compared to other > measures.

Re: Action on undisclosed intermediates

On 08/11/2016 20:37, Gervase Markham wrote: On 08/11/16 19:11, Jakob Bohm wrote: However because all the sources are from a single entity (the UK government), that entity could manipulate the results, thus falsifying the provable randomness of the process. I think you are bikeshedding the

WoSign still trusted somehow on Mac even after manual distrust of StartCom

You can see from image1 that all StartCom roots are marked distrust systemwide. No WoSign roots are included on Mac. However when I'm accessing https://www.schrauger.com/ in Chrome, the HTTPS connection is marked as valid (image2) and the certification authority of WoSign is regarded as a

Re: WoSign still trusted somehow on Mac even after manual distrust of StartCom

On Tue, Nov 8, 2016 at 2:23 PM, Percy wrote: > You can see from image1 that all StartCom roots are marked distrust > systemwide. No WoSign roots are included on Mac. > > However when I'm accessing https://www.schrauger.com/ in Chrome, the HTTPS > connection is marked as

Re: WoSign still trusted somehow on Mac even after manual distrust of StartCom

https://support.apple.com/en-us/HT204132 The source code for how Apple has implemented such blocks is available at https://opensource.apple.com/ Specifically https://opensource.apple.com/source/Security/Security-57337.60.2/OSX/libsecurity_apple_x509_tp/lib/tpCertAllowList.c.auto.html as called

Re: WoSign still trusted somehow on Mac even after manual distrust of StartCom

Yeah, I suspected so but I didn't find it in the security content (https://support.apple.com/en-ca/HT207275). I remember when Gerv discussed the idea on whitelisting intermediate cert, he mentioned that firefox didn't want to undermine user sovereignty by overriding the user's trust choice. I

Re: Implementing a SHA-1 ban via Mozilla policy

On 07/11/2016 15:00, Gervase Markham wrote: On 07/11/16 13:11, Phillip Hallam-Baker wrote: ... ... None of the current browser versions support SHA-1. Yes, they do. They won't as of January 2017. Since any policy change has no chance of taking effect before that date, they effectively

Re: Mozilla CT Policy

On 07/11/16 17:25, Ryan Sleevi wrote: > Yes. An 'evil log' can provide a divided split-view, targeting only > an affected number of users. Unless that SCT was observed, and > reported (via Gossip or some other means of exfiltration), that split > view would not be detected. So it is therefore

Re: Mozilla CA Policy 2.3 plan

On 07/11/16 20:05, Kathleen Wilson wrote: >> It would be useful if people checked it over to make sure I have not >> made any mistakes in conversion. The original is here, in four pages: >> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ > > Just one minor

Re: Mozilla CT Policy

On 2016-11-07 18:25, Ryan Sleevi wrote: This is why it's vitally important that clients fetch inclusion proofs in some manner Have you considered a TLS extension, have the server fetch them and send to the client? Kurt ___ dev-security-policy

Re: Implementing a SHA-1 ban via Mozilla policy

On 07/11/16 17:09, Nick Lamb wrote: > On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote: >> You mean EKU-constrained (e.g. to email, or OCSP only)? > > I was thinking also of a pathlen constraint. Aha. So what would this look like? Something like this? CAs may only issue SHA-1

RE: Implementing a SHA-1 ban via Mozilla policy

Gerv, GlobalSign generated some SHA-1 CAs earlier this year as part of normal CA lifecycle management. These CAs were generated to support S/MIME and client authentication products and we don’t intent to use them for SSL certificate issuance. These CAs are not technically constrained and