Re: Action on undisclosed intermediates

2016-11-09 Thread Rob Stradling
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Nick Lamb
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Kurt Roeckx
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Peter Bowen
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

RE: Can we require id-kp-serverAuth now?

2016-11-09 Thread 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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Peter Bowen
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Nick Lamb
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

Re: Action on undisclosed intermediates

2016-11-09 Thread Kathleen Wilson
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Gervase Markham
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Rob Stradling
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

RE: Can we require id-kp-serverAuth now?

2016-11-09 Thread Jeremy Rowley
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Jakob Bohm
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Rob Stradling
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Gervase Markham
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Gervase Markham
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Nick Lamb
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

Re: Can we require id-kp-serverAuth now?

2016-11-09 Thread Kurt Roeckx
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

Re: Implementing a SHA-1 ban via Mozilla policy

2016-11-09 Thread Gervase Markham
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

Re: Action on undisclosed intermediates

2016-11-09 Thread Gervase Markham
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

Re: Action on undisclosed intermediates

2016-11-09 Thread Gervase Markham
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"

Can we require id-kp-serverAuth now?

2016-11-09 Thread Gervase Markham
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],