Re: Technically Constrained Sub-CAs

[Matt Palmer]

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 certain type of crypto". If certs under TCSCs are
> exempt and this becomes popular, CT would become less useful for that.
> 
> 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 a
> valid reason not to do something. In other words, if you hide stuff and
> it breaks, you get to keep both pieces. But in practice, such a line
> might not hold.
> 
> Thoughts and suggestions?

I don't think TCSCs should be exempted from any CT requirements; as you say,
there is significant value in having a near-complete picture of the state of
the WebPKI.  There is extensive evidence that a browser's position that "if
your private stuff breaks, sucks to be you" will *not* stick in the face of
post-change breakage, regardless of how much notice certificate holders and
their issuers are given.  Only by knowing what is going on in the WebPKI can
browsers have any hope of not inadvertantly causing problems.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Matt Palmer]

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.

A brief examination of the explanations coming from organisations that have
requested SHA-1 issuance exceptions should provide a solid case study as to
how well *that's* going to work.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Ryan Sleevi]

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.

This is the only privacy mechanism that will be in -bis, it sounds
like. There was not consensus to remove it, since that would force it
to go back through WGLC. Instead, it will likely largely be ignored by
one major CT implementor (Chrome), but will exist in a documented
state that simply documents 'how' you could do it, not whether you
should. That is, the RFC documents technology, *not* policy.

While this is unfortunate, it's pragmatic - it allows 6962-bis to
carry on as-is, without having to restart discussion, even if it
contains technology that is unimplemented and will likely remain
unimplemented indefinitely. That's just SDOs as usual.

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 like it would significantly affect how you want
CT to play or not play in that role.

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
misissuance, in favor of something which clearly doesn't address the
use cases for redaction identified in the CA/Browser Forum and in the
IETF?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Taiwan GRCA Root Renewal Request

[Kathleen Wilson]

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 replace the 
previous GRCA root certificate that was included via Bugzilla Bug #274106. 

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Kathleen Wilson]

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: https://bugzilla.mozilla.org/attachment.cgi?id=8805546
> EV CPS: https://bug1128392.bmoattachments.org/attachment.cgi?id=8805547
> 
> Because of our English level, there maybe some mistakes. If you have any 
> questions, please contact us.


Thanks to all of you who have reviewed and commented on this request from 
Guangdong Certificate Authority (GDCA) is to include the "GDCA TrustAUTH R5 
ROOT" certificate, turn on the Websites trust bit, and enabled EV treatment. 

There were some recommendations to deny this request due to the versioning 
problems between the English documents and the original documents. 

Do you all still feel that is the proper answer to this root inclusion request?

Or should we proceed with reviewing these new English translations of the 
documents, and make our decision based on the new versions?

Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Apple's response to the WoSign incidents

[Tarah Wheeler]

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 or 
interstitial but also saw about 20 insecure content errors (not that everyone 
has Error Console running all the time). I also just hit a site I knew had an 
invalid certificate, and got a popup. Both sites show https inURL.


Respectfully,

Tarah Wheeler
Principal Security Advocate
Senior Director of Engineering, Website Security
Symantec
ta...@symantec.com


> On Nov 13, 2016, at 1:01 PM, "dev-security-policy-requ...@lists.mozilla.org" 
>  wrote:
> 
> Send dev-security-policy mailing list submissions to
>  dev-security-policy@lists.mozilla.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>  https://lists.mozilla.org/listinfo/dev-security-policy
> or, via email, send a message with subject or body 'help' to
>  dev-security-policy-requ...@lists.mozilla.org
> 
> You can reach the person managing the list at
>  dev-security-policy-ow...@lists.mozilla.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev-security-policy digest..."
> 
> 
> Today's Topics:
> 
> 1. Re: Action on undisclosed intermediates (Peter Bowen)
> 2. Re: Action on undisclosed intermediates (Rob Stradling)
> 3. Re: Comodo issued a certificate for an extension (Eric Mill)
> 4. Re: Apple's response to the WoSign incidents (Percy)
> 
> 
> --
> 
> Message: 1
> Date: Sat, 12 Nov 2016 09:43:36 -0800
> From: Peter Bowen 
> To: Gervase Markham 
> Cc: "mozilla-dev-security-pol...@lists.mozilla.org"
>  
> Subject: Re: Action on undisclosed intermediates
> Message-ID:
>  
> Content-Type: text/plain; charset=UTF-8
> 
>> On Tue, Nov 8, 2016 at 8:18 AM, Gervase Markham  wrote:
>> 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 good idea of many of them:
>> https://crt.sh/mozilla-disclosures#undisclosed
>> 
>> There is also a list on that page of certs which CAs have disclosed but
>> not provided audit info, but given that you can get off that list by
>> putting _anything_ in the relevant box in Salesforce, I'm worried about
>> perverse incentives if we go after people on that list at the moment:
>> https://crt.sh/mozilla-disclosures#disclosureincomplete
> 
> Based on data this morning, it looks like there are only two left on
> that undisclosed list.  One of them is RSA, who is already scheduled
> for removal.  The other is TurkTrust, which announced they are leaving
> the server auth cert business:
> https://cabforum.org/pipermail/public/2016-September/008475.html
> 
> So it seems this problem has resolved itself.  No need to invent
> random selection schemes.
> 
> Now, the real fun is going to be seeing if the supplied audit report
> URLs actually point to reports and if all the CAs claimed to be
> covered are actually covered ;)
> 
> Thanks,
> Peter
> 
> 
> --
> 
> Message: 2
> Date: Sat, 12 Nov 2016 20:11:50 +
> From: Rob Stradling 
> To: Peter Bowen , Gervase Markham
>  
> Cc: "mozilla-dev-security-pol...@lists.mozilla.org"
>  
> Subject: Re: Action on undisclosed intermediates
> Message-ID: <734f7b4e-9911-d28e-acdc-a95afa440...@comodo.com>
> Content-Type: text/plain; charset=windows-1252
> 
>> On 12/11/16 17:43, Peter Bowen wrote:
>> 
>> So it seems this problem has resolved itself.  No need to invent
>> random selection schemes.
> 
> ISTM that the threat of random selection schemes may have been what
> resolved the problem.  ;-)
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
> 
> 
> --
> 
> Message: 3
> Date: Sat, 12 Nov 2016 23:12:48 -0500
> From: Eric Mill 
> To: Robin Alden 
> Cc: Nick Lamb ,
>  "mozilla-dev-security-pol...@lists.mozilla.org"
>  
> Subject: Re: Comodo issued a certificate for an extension
> Message-ID:
>  
> Content-Type: text/plain; charset=UTF-8
> 
> Thank you for the update and for making it super clear, Robin.
> 
> -- Eric
> 
>> On Thu, Nov 10, 

Re: Technically Constrained Sub-CAs

[Rob Stradling]

[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
tomorrow!

Even if that option remains in 6962-bis, I'm not hopeful (based on
various comments from Ryan Sleevi) that Chrome's future 6962-bis
implementation will allow it.

My preference would be to move that option to
draft-strad-trans-redaction, so that further discussions and edits can
occur (that might make it more palatable to Chrome).  However, 6962-bis
has completed Working Group Last Call, so this may well not be possible.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Nick Lamb]

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 on network security.

Whereas I would say almost the precise opposite, the Web PKI is a _public_ 
resource, if you don't want your certificates to be examined by the _public_ 
then you are in the wrong place and need to look into a private CA. Redaction 
has no place in public CT logs. If a private CA wants to operate redacted logs 
in which everything is too murky to make any useful conclusions about anything 
they're welcome to do just that.

Even from this very limited perspective of protecting a subscriber from 
themselves, redaction falls down badly as I explained in my posts when Chromium 
mooted what redaction policies should be accepted earlier this year.

The snooping argument amounts to very little. If you were paying attention to 
CT logs when greatagain.gov was launched, or if you really stare hard at all 
the new certificates logged for the .gov TLD you will have discovered what 
Hillary's transition site would have been called. But amid a media saturated 
with wall-to-wall with US election news, focusing on even the tiniest slivers 
of new information, nobody even mentioned it. Not because the White House staff 
have some elite redaction technology that allowed them keep it off the record 
but because it's just not that interesting.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Andrew Ayer]

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
> > many certs use a certain type of crypto". If certs under TCSCs are
> > exempt and this becomes popular, CT would become less useful for that.
> >
> > 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 a
> > valid reason not to do something. In other words, if you hide stuff and
> > it breaks, you get to keep both pieces. But in practice, such a line
> > might not hold.
> 
> I think this is the right answer.  Yes, CT has helped provide a better
> view into galaxy of CAs that is WebPKI, that was not its stated
> purpose.  CT was created to help domain registrants have visibility
> into what is issued for their domain names.

I disagree with your characterization of CT.  The first sentences of
RFC6962 say:

"Certificate transparency aims to mitigate the problem of misissued
certificates by providing publicly auditable, append-only, untrusted
logs of all issued certificates.  The logs are publicly auditable so
that it is possible for anyone to verify the correctness of each log
and to monitor when new certificates are added to it.  The logs do
not themselves prevent misissue, but they ensure that interested
parties (particularly those named in certificates) can detect such
misissuance."

Although issuing a certificate without the authorization of the domain
registrant is the most serious type of misissuance, it is not the only
type.  Apart from audits, TCSCs are subject to the Baseline
Requirements, and failure to comply is a type of misissuance that is of
interest to the Internet community, particularly to root store
operators and certificate validation implementers like Mozilla.

In any case, standards can provide unexpected benefits.  It would
be self-defeating to discount a benefit just because it wasn't
originally stated as a goal of the standard.

> 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.

Unfortunately, domain holders do not act rationally.  Just look at all
the domain holders who requested redacted franken-certificates from
Symantec for publicly-accessible websites even when it was immediately
apparent that such certificates do not work in Chrome.  Domain holders
would likewise fail to take heed that certificates issued from TCSCs
might stop working at some point in the future, and probably in greater
numbers since the consequences of their actions would be more abstract
and less proximate.

Meanwhile, end users have no say over what certificate a site uses
and just want their browser to work.  No browser maker wants to break
sites for users.  The rule about ignoring TCSCs when making decisions
will surely be reverted the first time it causes widespread breakage.
Then we'll be back in the same situation we are in now, where the lack
of complete information makes it difficult to make changes that
improve the security and robustness of the Web PKI.

I appreciate the need for domain name privacy, but it must be balanced
against the needs of the public.  I find the label redaction approach
in draft-strad-trans-redaction-00 to be more balanced, as it hides only
the minimum amount of information needed to provide domain name privacy.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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 think you are overstating the in-practice benefits of attempting to
keep your internal hostnames secret.

As a wise person pointed out at CAB Forum, if I wanted to find out lots
of hostnames on Microsoft's internal network, I would just run a network
sniffer at the local Starbucks and look at what DNS requests were made.

Also, wildcards are an additional mechanism by which you can keep the
leftmost part of your hostname private, for subdomains.

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Peter Bowen]

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 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, only that it
>>> hasn't been done so far. But I did wonder about auditors witnessing key
>>> ceremonies - would that be a necessary component? Does that make things
>>> more complicated?
>>
>>
>> 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 during the key generation ceremony
>> 3) There is no requirement that each CA have a unique key pair.
>>
>> Combine all three of these and there are multiple paths to easy TCSC
>> creation.
>>
>
> #3 would be in apparent violation of the BR applicability document you
> proposed in another thread.  Alternative would be to pre-create
> resellable TCSC key pairs in advance during auditor visits, then throw
> away unsold ones at the next such ceremony.

#3 doesn't violate the doc I proposed.  The callout is that a non-Root
CA may not share a key pair with a Root CA and that a single CA may
not have multiple key pairs (e.g. don't attempt key rotation without
changing the name).  It is completely permissible to have multiple CAs
with the same key pair as long as all have the same operator.

I think you are pointing out the need for a diagram.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Jakob Bohm]

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 to imply that it was hard or easy, only that it
hasn't been done so far. But I did wonder about auditors witnessing key
ceremonies - would that be a necessary component? Does that make things
more complicated?


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 during the key generation ceremony
3) There is no requirement that each CA have a unique key pair.

Combine all three of these and there are multiple paths to easy TCSC
creation.



#3 would be in apparent violation of the BR applicability document you
proposed in another thread.  Alternative would be to pre-create
resellable TCSC key pairs in advance during auditor visits, then throw
away unsold ones at the next such ceremony.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Eric Mill]

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 a
> > valid reason not to do something. In other words, if you hide stuff and
> > it breaks, you get to keep both pieces. But in practice, such a line
> > might not hold.
>
> I think this is the right answer.  Yes, CT has helped provide a better
> view into galaxy of CAs that is WebPKI, that was not its stated
> purpose.  CT was created to help domain registrants have visibility
> into what is issued for their domain names.


CT's original purpose is useful to know, but not as important as what
benefit Mozilla wishes to gain from CT as a root program and browser.

Right now, there aren't a lot of TCSCs, and so the impact to ecosystem
visibility is small. Once they're made easy to mint (which seems like a
good thing) an exemption from CT could, over time, drastically impact the
ecosystem visibility benefits that CT has demonstrated (which seems like a
bad thing).

Chrome's been really clear that, CT spec or not, the use of a TCSC isn't
enough to get out of SCT requirements. At least until the community does
more work at identifying name redaction use cases and how to best address
them over the next few months, I would recommend Mozilla stick with
Chrome's position.

-- Eric


> 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.
>
> Thanks,
> Peter
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Gervase Markham]

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 during the key generation ceremony
> 3) There is no requirement that each CA have a unique key pair.
> 
> Combine all three of these and there are multiple paths to easy TCSC
> creation.

OK, makes sense, thank you.

Does anyone think that any of these 3 lack-of-requirements presents a
risk? I can't see one immediately but it's worth asking the question.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Peter Bowen]

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, only that it
> hasn't been done so far. But I did wonder about auditors witnessing key
> ceremonies - would that be a necessary component? Does that make things
> more complicated?

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 during the key generation ceremony
3) There is no requirement that each CA have a unique key pair.

Combine all three of these and there are multiple paths to easy TCSC
creation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Kurt Roeckx]

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 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.

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 certain type of crypto". If certs under TCSCs are
exempt and this becomes popular, CT would become less useful for that.

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 a
valid reason not to do something. In other words, if you hide stuff and
it breaks, you get to keep both pieces. But in practice, such a line
might not hold.

Thoughts and suggestions?


Before there was CT, we already made decisions based on those 
certificates that we actually get to see based on various ways to see 
them. It's also not because they won't be required to be in CT they 
won't end up in CT, either because they really don't have a reason to 
hide them or that other people that saw the certificate added them.



Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Peter Bowen]

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.

It is very easy to mint TCSCs at scale without violating the letter or
the spirit of the BRs and other requirements.

> 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 certain type of crypto". If certs under TCSCs are
> exempt and this becomes popular, CT would become less useful for that.
>
> 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 a
> valid reason not to do something. In other words, if you hide stuff and
> it breaks, you get to keep both pieces. But in practice, such a line
> might not hold.

I think this is the right answer.  Yes, CT has helped provide a better
view into galaxy of CAs that is WebPKI, that was not its stated
purpose.  CT was created to help domain registrants have visibility
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.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Technically Constrained Sub-CAs

[Gervase Markham]

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 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.

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 certain type of crypto". If certs under TCSCs are
exempt and this becomes popular, CT would become less useful for that.

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 a
valid reason not to do something. In other words, if you hide stuff and
it breaks, you get to keep both pieces. But in practice, such a line
might not hold.

Thoughts and suggestions?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Mozilla CA Policy 2.3 plan

[Gervase Markham]

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 additional issue (references to new ETSI docs) which needed
resolving, but which is now resolved. So we think version 2.3 is now
ready to ship, and become immediately applicable. See the diff URL above
for the changes.

Last chance to raise objections! :-)

(The BR version number update is to the one that has been in the draft
2.3 policy for ages, rather than to the latest version; that's intentional.)

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Rob Stradling]

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 for some reason:
https://cabforum.org/pipermail/public/2016-October/008592.html

Andrew's document is "available here":
https://drive.google.com/open?id=0B8nbdAUn7RfQOElGNlhaQTJmYWM


Here's what his post said:

"Greetings,

As I mentioned at the face to face meeting, Gmail will be rolling out
the ability for some users to protect their email with S/MIME.  While
the product details will be announced in due course, we have produced a
profile that must be met for certificates to pass validation. In terms
of accepted roots, the list is yet to be published but those roots that
have the email trust bit set for the programs currently using the CA
Community in Salesforce are highly likely to be accepted.

The document is available here.

Please let me know if you have any comments or questions,

Thanks,

Andrew"

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham]

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 Root CAs are included in multiple browser trust
> stores.  For example, forbidding DSA would impact all browsers.

Please note that in the appropriate bug :-)

>>> Certification Authority (CA) - a logical entity which uses its private
>>> key to sign certificates.
>>
>> Is this too broad? An intermediate certificate might meet this
>> definition. Why do we need this definition if we have CAO and CAKP?
> 
> A CA is not a certificate.  It is the tuple (CAKP, CADN).

Ah. That would be a useful explanatory extra sentence.

> This comes directly from RFC 5280, section 3.2:
> 
>   "This specification covers two classes of certificates: CA
>certificates and end entity certificates.  CA certificates may be
>further divided into three classes: cross-certificates, self-issued
>certificates, and self-signed certificates. 

That's as may be, but I suggest that normal usage has moved on. I
certainly don't see that usage of cross-certificate.

>>> 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?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Action on undisclosed intermediates

[Gervase Markham]

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 so perhaps all of the problems they were having
suddenly got solved.

Anyway, on to something else :-)

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham]

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:

https://bugzilla.mozilla.org/show_bug.cgi?id=1317245

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy