Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 11:46:28AM +, Gervase Markham wrote: > CT is getting to be very useful as a way of surveying the certificate > ecosystem. This is helpful to assess the impact of proposed policy > changes or positions, e.g. "how many certs don't have an EKU", or "how > many certs use a

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 06:00:24AM -0800, Peter Bowen wrote: > into what is issued for their domain names. If domain holders want to > keep their certificates semi-private, then they need to be aware that > security is a moving target and their input on data-driven decisions > may be diminished.

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham wrote: > If this is the only privacy mechanism available for 6962bis, I suspect > we will see a lot more TCSCs about, particularly if CAs figure out ways > to mint them at scale within the letter of the BRs and other requirements.

Re: Taiwan GRCA Root Renewal Request

All, I will greatly appreciate it if you will review this request from Government of Taiwan, Government Root Certification Authority (GRCA) to include their Government Root Certification Authority root certificate, and turn on the Websites and Email trust bits. This root cert will eventually

Re: Guang Dong Certificate Authority (GDCA) root inclusion request

On Friday, October 28, 2016 at 7:29:56 AM UTC-7, wangs...@gmail.com wrote: > We have uploaded the lastest translantion of CP/CPS. > CP: https://bugzilla.mozilla.org/attachment.cgi?id=8805543 > CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805545 > EV CP:

Re: Apple's response to the WoSign incidents

If Apple is using wildcards that permit an otherwise-banned certificate, it seems like not only a regex problem--and who hasn¹t had those before?-- but also a rather disturbing workaround for certs that otherwise should not be respected. I just hit this site in Safari on a Mac and got no popup

Re: Technically Constrained Sub-CAs

[Resending due to nondelivery on two earlier attempts] On 14/11/16 11:46, Gervase Markham wrote: > Hi all, > > RFC 6962bis (the new CT RFC) allows certs below technically-constrained > sub-CAs (TCSCs) to be exempt from CT. 6962-bis may or may not still say that after the TRANS meeting in Seoul

Re: Technically Constrained Sub-CAs

On Monday, 14 November 2016 16:57:20 UTC, Jakob Bohm wrote: > If this is the only privacy mechanism in 6962bis, I would suggest that > everyone not employed by either Google or another mass-monitoring > service block its adoption on human rights grounds and on the basis of > being a mass-attack

Re: Technically Constrained Sub-CAs

On Mon, 14 Nov 2016 06:00:24 -0800 Peter Bowen wrote: > > CT is getting to be very useful as a way of surveying the certificate > > ecosystem. This is helpful to assess the impact of proposed policy > > changes or positions, e.g. "how many certs don't have an EKU", or "how > >

Re: Technically Constrained Sub-CAs

On 14/11/16 16:56, Jakob Bohm wrote: > If this is the only privacy mechanism in 6962bis, I would suggest that > everyone not employed by either Google or another mass-monitoring > service block its adoption on human rights grounds and on the basis of > being a mass-attack on network security. I

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 8:51 AM, Jakob Bohm wrote: > On 14/11/2016 16:31, Peter Bowen wrote: >> >> On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham wrote: >>> >>> On 14/11/16 14:00, Peter Bowen wrote: It is very easy to mint TCSCs at scale

Re: Technically Constrained Sub-CAs

On 14/11/2016 16:31, Peter Bowen wrote: On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham wrote: On 14/11/16 14:00, Peter Bowen wrote: It is very easy to mint TCSCs at scale without violating the letter or the spirit of the BRs and other requirements. I guess I didn't mean

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 9:00 AM, Peter Bowen wrote: > On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham wrote: > > > > One possible answer is just to say: "Mozilla will not accept 'but we > > have a lot of certs under TCSCs which will be affected by this' as

Re: Technically Constrained Sub-CAs

On 14/11/16 15:31, Peter Bowen wrote: > 1) Auditors are not required to witness key generation ceremonies for > non-Root CA keys when the new CA is operated by the same entity as the > parent CA. > 2) There is no requirement that the binding between CA distinguished name > and key pair occur

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 7:14 AM, Gervase Markham wrote: > On 14/11/16 14:00, Peter Bowen wrote: >> It is very easy to mint TCSCs at scale without violating the letter or >> the spirit of the BRs and other requirements. > > I guess I didn't mean to imply that it was hard or easy,

Re: Technically Constrained Sub-CAs

On 2016-11-14 12:46, Gervase Markham wrote: Hi all, RFC 6962bis (the new CT RFC) allows certs below technically-constrained sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy. TCSCs themselves are also currently exempt from disclosure to Mozilla in the Common CA Database. If

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 3:46 AM, Gervase Markham wrote: > > If this is the only privacy mechanism available for 6962bis, I suspect > we will see a lot more TCSCs about, particularly if CAs figure out ways > to mint them at scale within the letter of the BRs and other

Technically Constrained Sub-CAs

Hi all, RFC 6962bis (the new CT RFC) allows certs below technically-constrained sub-CAs (TCSCs) to be exempt from CT. This is to allow name privacy. TCSCs themselves are also currently exempt from disclosure to Mozilla in the Common CA Database. If this is the only privacy mechanism available

Re: Mozilla CA Policy 2.3 plan

On 07/11/16 14:08, Gervase Markham wrote: > the 2.3 draft says for some time. Therefore, it seems to me that we > could ship the current draft version as version 2.3 immediately, with > immediate applicability. Diff: > https://github.com/mozilla/pkipolicy/compare/2.2...master We found one

Re: Proposal to define applicability of BRs and expectations of CAs

On 14/11/16 09:25, Gervase Markham wrote: a) Ensure the End-Entity certificates follows the S/MIME Certificate Profile: Minimum >>> >>> What is that? >> >> The Google draft Andrew Whalley published. > > I'm not sure I'm familiar with that; URL? The archive of Andrew's post is empty

Re: Proposal to define applicability of BRs and expectations of CAs

On 11/11/16 19:51, Peter Bowen wrote: >> The following issues with our current policy may be relevant: >> https://github.com/mozilla/pkipolicy/issues/27 >> https://github.com/mozilla/pkipolicy/issues/5 > > I think any increase in requirements needs to be carefully considered > given that many

Re: Action on undisclosed intermediates

On 12/11/16 17:43, Peter Bowen wrote: > So it seems this problem has resolved itself. No need to invent > random selection schemes. As Rob says, one could speculate on the connection between the proposal and the sudden action. Although Kathleen did say she was in contact with most of these CAs

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

On 09/11/16 09:58, 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? I don't think there is, so I've filed a bug on it: