Re: Technically Constrained Sub-CAs

On 21/11/16 19:01, Brian Smith wrote: > In another message in this thread, I suggested one way to mark intermediate > certificates as meeting the criteria of an name-constrained > externally-operated sub-CA that uses certificate policy OIDs. That proposed > mechanism also ensures

Re: Technically Constrained Sub-CAs

On Mon, Nov 21, 2016 at 11:51 AM, Brian Smith wrote: > Nobody said anything about blocking 6962-bis. Removing that one section is a > smaller change in terms than the change Google made to the document just > last week, as far as the practical considerations are concerned.

Re: Technically Constrained Sub-CAs

Ryan Sleevi wrote: > On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith > wrote: > > Absolutely we should be encouraging them to proliferate. Every site that > is > > doing anything moderately complex and/or that wants to use key pinning > > should be using

Re: Technically Constrained Sub-CAs

On Mon, Nov 21, 2016 at 11:01 AM, Brian Smith wrote: > Absolutely we should be encouraging them to proliferate. Every site that is > doing anything moderately complex and/or that wants to use key pinning > should be using them. I do hope you can expand upon the former as to

Re: Technically Constrained Sub-CAs

Gervase Markham wrote: > On 18/11/16 19:13, Brian Smith wrote: > > Regardless, the main point of that message of mine was left out: You > could > > limit, in policy and in code, the acceptable lifetime of name-constrained > > externally-operated sub-CAs > > Presumably the

Re: Technically Constrained Sub-CAs

On 18/11/16 20:21, Brian Smith wrote: I think there might be ways to fix the name-constrained sub-CA stuff for RFC 6962-bis, but those kinds of improvements are unlikely to happen in RFC 6962-bis itself, it seems. They will have to happen in an update to RFC 6962-bis. I also disagree with

Re: Technically Constrained Sub-CAs

Hi Brian, On 18/11/16 19:13, Brian Smith wrote: > Regardless, the main point of that message of mine was left out: You could > limit, in policy and in code, the acceptable lifetime of name-constrained > externally-operated sub-CAs Presumably the "externally-operated" part would need to be

Re: Technically Constrained Sub-CAs

Gervase Markham <g...@mozilla.org> wrote: > 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

Re: Technically Constrained Sub-CAs

Gervase Markham wrote: > On 18/11/16 01:43, Brian Smith wrote: > > The fundamental problem is that web browsers accept certificates with > > validity periods that are years long. If you want to have the agility to > > fix things with an N month turnaround, reject certificates

Re: Technically Constrained Sub-CAs

On 18/11/16 14:28, Jeremy Rowley wrote: > So much has changed since the last time we discussed shorter > validity periods at CAB forum that it'd be worth bringing up again. I > think the vocal minority opposed the change last time and they may > have switched positions by now. I like your

Re: Technically Constrained Sub-CAs

So much has changed since the last time we discussed shorter validity periods at CAB forum that it'd be worth bringing up again. I think the vocal minority opposed the change last time and they may have switched positions by now. > On Nov 18, 2016, at 7:12 AM, Gervase Markham

Re: Technically Constrained Sub-CAs

On 18/11/16 01:43, Brian Smith wrote: > The fundamental problem is that web browsers accept certificates with > validity periods that are years long. If you want to have the agility to > fix things with an N month turnaround, reject certificates that are valid > for more than N months. That's all

Re: Technically Constrained Sub-CAs

On 18/11/16 00:28, Andrew Ayer wrote: > I see the appeal of this. However, I'm concerned that allowing > leniency with name-constrained TCSCs will make it hard for Mozilla to > make security improvements to its certificate validation in the > future. Improvements like rejecting SHA-1, 1024-bit

Re: Technically Constrained Sub-CAs

On 18/11/2016 06:23, Brian Smith wrote: Andrew Ayer wrote: The N month turnaround is only a reality if operators of TCSCs start issuing certificates that comply with the new rules as soon as the new rules are announced. How do you ensure that this happens? Imagine

Re: Technically Constrained Sub-CAs

Andrew Ayer wrote: > The N month turnaround is only a reality if operators of TCSCs start > issuing certificates that comply with the new rules as soon as the new > rules are announced. How do you ensure that this happens? > Imagine that the TCSCs are also required to

Re: Technically Constrained Sub-CAs

On Thu, Nov 17, 2016 at 04:55:37PM -0800, Peter Bowen wrote: > On Thu, Nov 17, 2016 at 4:38 PM, Matt Palmer wrote: > >> (Note: Key pinning isn't the only advantage to being able to freely operate > >> your own intermediate CA.) > > > > I don't see how freely operating your

Re: Technically Constrained Sub-CAs

Ryan Sleevi wrote: > On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb wrote: > > There's a recurring pattern in most of the examples. A technical > counter-measure would be possible, therefore you suppose it's OK to > screw-up and the counter-measure saves us. I

Re: Technically Constrained Sub-CAs

On Thu, Nov 17, 2016 at 3:12 PM, Nick Lamb wrote: > There's a recurring pattern in most of the examples. A technical > counter-measure would be possible, therefore you suppose it's OK to screw-up > and the counter-measure saves us. I believe this is the wrong attitude.

Re: Technically Constrained Sub-CAs

On Thu, Nov 17, 2016 at 02:10:58PM -1000, Brian Smith wrote: > Nick Lamb wrote: > > There's a recurring pattern in most of the examples. A technical > > counter-measure would be possible, therefore you suppose it's OK to > > screw-up and the counter-measure saves us. > >

Re: Technically Constrained Sub-CAs

On Thu, 17 Nov 2016 09:28:43 -1000 Brian Smith wrote: > On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi wrote: > > > As Andrew Ayer points out, currently, CAs are required to ensure > > TCSCs comply with the BRs. Non-compliance is misissuance. Does > >

Re: Technically Constrained Sub-CAs

Nick Lamb wrote: > There's a recurring pattern in most of the examples. A technical > counter-measure would be possible, therefore you suppose it's OK to > screw-up and the counter-measure saves us. Right. > I believe this is the wrong attitude. These counter-measures

Re: Technically Constrained Sub-CAs

On Thursday, 17 November 2016 19:28:54 UTC, Brian Smith wrote: > Let's say I screw up something and accidentally issue a certificate from my > sub-CA for google.com or addons.mozilla.org. Because of the name > constraints, this is a non-issue and shouldn't result in any sanctions on > the

Re: Technically Constrained Sub-CAs

On Mon, Nov 14, 2016 at 6:39 PM, Ryan Sleevi wrote: > As Andrew Ayer points out, currently, CAs are required to ensure TCSCs > comply with the BRs. Non-compliance is misissuance. Does Mozilla share > that view? And is Mozilla willing to surrender the ability to detect >

Re: Technically Constrained Sub-CAs

On 17/11/2016 01:14, Matt Palmer wrote: On Wed, Nov 16, 2016 at 04:35:18PM +0100, Jakob Bohm wrote: Redacted CT records that tell the world that "there is this single certificate with this full TBS hash and these technical extensions issued to some name domain/e-mail under example.com, but it

Re: Technically Constrained Sub-CAs

On 16/11/2016 02:13, Nick Lamb wrote: On Tuesday, 15 November 2016 09:35:17 UTC, Jakob Bohm wrote: The HTTPS-everywhere tendency, including the plans of some people to completely remove unencrypted HTTP from implementations, makes it necessary for non-public stuff connected to the Internet to

Re: Technically Constrained Sub-CAs

On Tue, Nov 15, 2016 at 7:27 AM, Gervase Markham wrote: > I certainly think our view of redaction will be driven by use cases. > AIUI, you are strongly encouraging use cases to be brought to the IETF. > However, if 6962bis is in Last Call, and won't be updated, is the TRANS >

Re: Technically Constrained Sub-CAs

On Tuesday, 15 November 2016 09:35:17 UTC, Jakob Bohm wrote: > The HTTPS-everywhere tendency, including the plans of some people to > completely remove unencrypted HTTP from implementations, makes it > necessary for non-public stuff connected to the Internet to get > Internet-compatible TLS

Re: Technically Constrained Sub-CAs

On Tue, Nov 15, 2016 at 04:27:09PM +0100, Gervase Markham wrote: > I certainly think our view of redaction will be driven by use cases. > AIUI, you are strongly encouraging use cases to be brought to the IETF. > However, if 6962bis is in Last Call, and won't be updated, is the TRANS > group still

Re: Technically Constrained Sub-CAs

On 15/11/16 05:39, Ryan Sleevi wrote: > I think it'd be useful to resolve the questions I asked on this thread > - > https://groups.google.com/d/msg/mozilla.dev.security.policy/ZMUjQ6xHrDA/ySofsF_PAgAJ > - to figure out what Mozilla expects/wants of TCSCs with respect to > the BRs, as that seems

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: 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 meet

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

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: Technically Constrained Sub-CAs and the BRs

> Certificates that are capable of being used to issue new certificates MUST > either be Technically Constrained in line with section 7.1.5 and audited in > line with section 8.7 only, or Unconstrained and fully audited in line with > all remaining requirements from this section > > Section

Re: Technically Constrained Sub-CAs and the BRs

On 26/10/16 18:53, Ryan Sleevi wrote: > interpretation of #2. This is also why I support the mandatory > disclosure of TCSCs to Mozilla Salesforce, to ensure that the > Technical Constraints are properly implemented and conforming in > order for the CA to claim its exclusion. If we were to

RE: Technically Constrained Sub-CAs and the BRs

-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Ryan Sleevi Sent: Wednesday, October 26, 2016 11:53 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Technically Constrained Sub-CAs and the BRs On Wednesday, October 26

Re: Technically Constrained Sub-CAs and the BRs

On Wednesday, October 26, 2016 at 3:52:23 AM UTC-7, Gervase Markham wrote: > Perhaps it would be worth revisiting the reasons why technically > constrained sub-CAs were excluded from Mozilla policy. As I remember, > this was a privacy requirement - CAs wanted to be able to have some

Re: Technically Constrained Sub-CAs and the BRs

Reading this makes me wonder. Will it still be possible to have such a thing as a non disclosed sub-CA now that Chrome has announced that they soon will require CT? CU Hans ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Technically Constrained Sub-CAs and the BRs

ccordance with > Mozilla’s CA Certificate Policy and MUST either be technically constrained or > be publicly disclosed and audited. > > This wording implies that technically constrained sub-CAs, from a Mozilla > Policy standpoint, are not required to adhere to the Baseline Requirements. So I

Re: Technically Constrained Sub-CAs and the BRs

requires it, we need to make sure that Mozilla's application of the BRs is correctly scoped. Perhaps it would be worth revisiting the reasons why technically constrained sub-CAs were excluded from Mozilla policy. As I remember, this was a privacy requirement - CAs wanted to be able to have so

Re: Technically Constrained Sub-CAs and the BRs

On Wednesday, 26 October 2016 02:31:07 UTC+1, Ryan Sleevi wrote: > Yes. There is no obligation or expectation, presently communicated, to revoke > extant certificates. Indeed, CAs were adamantly opposed to such a > requirement. So these certificates will still very much be valid. Ah yes, I had

Re: Technically Constrained Sub-CAs and the BRs

On Tuesday, October 25, 2016 at 4:56:57 PM UTC-7, Nick Lamb wrote: > Is it possible for someone to write up the details of the non-compliant > issuances and so on ? I would find it much easier to comment on the > particulars of 1311200 if they were more specific. This doesn't seem relevant;

Re: Technically Constrained Sub-CAs and the BRs

On Tuesday, 25 October 2016 21:16:36 UTC+1, Ryan Sleevi wrote: > The linked bug is a concrete example, where an unconstrained sub-CA was > revoked, due to non-compliance with the BRs, but has now been cross-certified > as a constrained sub-CA. All of these non-BR compliant certificates are now

Re: Technically Constrained Sub-CAs and the BRs

On Tue, Oct 25, 2016 at 12:12:47PM -0700, Ryan Sleevi wrote: > That is, according to the BRs, the issuer of a technically constrained > subordinate CA has a BR-obligation to ensure that their TCSCs are adhering to > the BRs and the issuing CA's policies and practices, as well as conduct a >

Technically Constrained Sub-CAs and the BRs

Certificate Program, MUST be operated in accordance with Mozilla’s CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited. This wording implies that technically constrained sub-CAs, from a Mozilla Policy standpoint, are not required to adhere to the Baseline