On 09/11/16 17:36, Kathleen Wilson wrote:
> On Wednesday, November 9, 2016 at 4:16:56 AM UTC-8, Rob Stradling wrote:
>> To have reached the incorrect conclusion that they'd "properly followed
>> the requirement", a CA would've presumably either...
>> 1. Looked at
On Wednesday, 9 November 2016 18:50:25 UTC, Peter Bowen wrote:
> Here are some certs that appear to be for server authentication but
> don't have that EKU:
>
> https://crt.sh/?id=10621190
I didn't look at all of these, but
* The issuer isn't trusted by Mozilla, so arguably it's out of scope in
On Wed, Nov 09, 2016 at 10:57:54AM -0800, Peter Bowen wrote:
> I think it makes sense to have a new doc that applies to all CAs and
> specifies when requirements apply to certificates. That way we can
> say "SSL BRs apply if X, S/MIME BRs apply if Y, Code Signing applies
> if Z, this doc applies
I think it makes sense to have a new doc that applies to all CAs and
specifies when requirements apply to certificates. That way we can
say "SSL BRs apply if X, S/MIME BRs apply if Y, Code Signing applies
if Z, this doc applies to subCAs when A".
On Wed, Nov 9, 2016 at 10:55 AM, Jeremy Rowley
Perhaps the CA didn't intend them to be used for Web PKI, making them out of
scope of the BRs. Playing devil's advocate, I'd say anything issued without
serverAuth isn't intended to be used for server authentication by the CA.
Because of this, either the CAB Forum should define all certs with
On Wed, Nov 9, 2016 at 1:58 AM, Gervase Markham wrote:
> So, it is now possible to change Firefox to mandate the presence of
> id-kp-serverAuth for EE server certs from Mozilla-trusted roots? Or is
> there some reason I've missed we can't do that?
Here are some certs that
On Wednesday, 9 November 2016 13:03:37 UTC, Gervase Markham wrote:
> On 09/11/16 12:17, Nick Lamb wrote:
>
> > I am not always very clear on how Censys queries work, but I believe this
> > query is a useful starting point (within the limited context of Censys)
> >
> > current_valid_nss: true
On Wednesday, November 9, 2016 at 4:16:56 AM UTC-8, Rob Stradling wrote:
> To have reached the incorrect conclusion that they'd "properly followed
> the requirement", a CA would've presumably either...
> 1. Looked at https://crt.sh/mozilla-disclosures#undisclosed, noticed
> that one or more of
On 09/11/16 16:10, Jeremy Rowley wrote:
> 7.1.2.3 requires an EKU but does not require serverAuth. clientAuth is
> permissible.
Yes, that is true, but I'm not sure it's relevant to the point. There
are two types of BR-compatible cert:
EKU-serverAuth
EKU-clientAuth
Either may have other EKUs
On 09/11/16 14:06, Jakob Bohm wrote:
> On 09/11/2016 14:26, Rob Stradling wrote:
>> ...
>> On 09/11/16 13:02, Gervase Markham wrote:
>>> ...
>>> I can't seem to
>>> use censys.io to work out why it thinks we trust it, because I thought
>>> that we didn't trust all of that stuff.
>>
>> Paths from
7.1.2.3 requires an EKU but does not require serverAuth. clientAuth is
permissible. Omitting other values is only a "SHOULD"
This is back to the same problem we keep going round and round again. Only
certificates intended for web servers are considered in scope of the BRs.
Therefore, the BRs only
On 09/11/2016 14:26, Rob Stradling wrote:
...
On 09/11/16 13:02, Gervase Markham wrote:
...
I can't seem to
use censys.io to work out why it thinks we trust it, because I thought
that we didn't trust all of that stuff.
Paths from this cert up to an NSS built-in root do exist, but they all
On 09/11/16 13:02, Gervase Markham wrote:
>> A couple of examples that look to me as though they might be able to be
>> installed in a web server yet lack the EKU:
>>
>> https://censys.io/certificates/127f386498e3cfd330e40699b92efb68b72bfaa08af68f9a0fe959b1fea3ae9c
>
> This one's in the Federal
On 09/11/16 12:17, Nick Lamb wrote:
> I am not always very clear on how Censys queries work, but I believe this
> query is a useful starting point (within the limited context of Censys)
>
> current_valid_nss: true AND (NOT parsed.extensions.extended_key_usage:1)
That query produces 8,090
On 09/11/16 10:43, Kurt Roeckx wrote:
> On 2016-11-09 10:58, Gervase Markham wrote:
>> At the moment, Firefox recognises an EE cert as a server cert if it has
>> an EKU extension with id-kp-serverAuth, or if it has no EKU at all.
>
> So not when the anyExtendedKeyUsage is present?
No. I believe
On Wednesday, 9 November 2016 09:59:10 UTC, Gervase Markham wrote:
> The current maximum lifetime of a BR cert is 39 months. 17th Feb 2013 is
> more than 39 months ago. (Even if it were previously possible to issue
> longer certs and some may still be around, those will all be SHA-1, and
> so no
On 2016-11-09 10:58, Gervase Markham wrote:
At the moment, Firefox recognises an EE cert as a server cert if it has
an EKU extension with id-kp-serverAuth, or if it has no EKU at all.
So not when the anyExtendedKeyUsage is present?
> On 17th of Feb 2013, Mozilla published CA policy 2.1, which
On 08/11/16 11:17, Gervase Markham wrote:
> Aha. So what would this look like? Something like this?
And we would need phase-in periods for both the requirements on
intermediate certs, and the requirements on end-entity certs. And the
former may have to be a bit longer than the latter, as cutting
On 08/11/16 21:09, Kathleen Wilson wrote:
> I've been exchanging email and working with just about all of these
> CAs. There have been a few problems in our Salesforce customization
> to work out, and there have been some questions about which
> intermediate certs needed to be disclosed (regarding
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"
At the moment, Firefox recognises an EE cert as a server cert if it has
an EKU extension with id-kp-serverAuth, or if it has no EKU at all.
On 17th of Feb 2013, Mozilla published CA policy 2.1, which required
adherence to the BRs (version 1.1.5).[0]
Since the very first version of the BRs[1],
21 matches
Mail list logo