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
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
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
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
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
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"
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
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.
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
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
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
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
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
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
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
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
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,
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".
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
33 matches
Mail list logo