Re: Include Symantec-brand Class 1 and Class 2 Root Certs

[Kathleen Wilson]

On Tuesday, November 15, 2016 at 3:58:26 PM UTC-8, Kathleen Wilson wrote:
> If there are no objections or concerns about this request, then I will 
> recommend approval in the bug.


Thanks to those of you who reviewed and commented on this request from Symantec 
to include their Symantec-brand Class 1 and Class 2 root certs and enable the 
email trust bit for them.

I am now closing this discussion and will recommend approval in the bug.

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

Any further follow-up on this request should be added directly to the bug.

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

Re: SHA-1 Phase-out

[Myers, Kenneth (10421)]

Hi Gerv,

I've been trying to stay on top of the SHA-1 phase-out discussion but lost 
track. Where did it leave off?

I think I saw something of doing a ban at the browser level to not trust the 
SHA-1 algorithm. Is this possible?

Kenneth Myers
Manager
+1.571.366.6120 +1.703.299.3046 fax
Protiviti | 1640 King Street | Suite #400 | Alexandria | VA 22314 US | 
Protiviti.com
NOTICE: Protiviti is a global consulting and internal audit firm composed of 
experts specializing in risk and advisory services. Protiviti is not licensed 
or registered as a public accounting firm and does not issue opinions on 
financial statements or offer attestation services. This electronic mail 
message is intended exclusively for the individual or entity to which it is 
addressed. This message, together with any attachment, may contain confidential 
and privileged information. Any views, opinions or conclusions expressed in 
this message are those of the individual sender and do not necessarily reflect 
the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, 
printing, copying, retention, disclosure or distribution is strictly 
prohibited. If you have received this message in error, please immediately 
advise the sender by reply email message to the sender and delete all copies of 
this message. Thank you.
___
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 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.

With IETF process, having completed WGLC, it would, effectively,
require blocking it, so as to send it back to the WG, remove it,
re-enter WGLC, and recomplete.

That is, the time for that comment is more or less over, as Rob
Stradling found out with respect to the chairs' position on that
matter.

> Regardless, the argument for removing it is exactly your own arguments for
> why you don't want to do it in Chrome. Read your own emails to learn more
> about my technical objections to it.

Have you supplied those to TRANS? Have you provided compelling
evidence that the document, as currently written, is so flawed that it
would need to re-enter WGLC?

The process point alone is enough to let it alone, and it doesn't seem
like you're proposing any substantial technical change to it; that is,
the substance of the changes are attached to policy, not the technical
definition.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Brian Smith]

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 them.
>
> I do hope you can expand upon the former as to what you see.
> As to the latter, key pinning is viable without the use of TCSCs.


A lot of people disagree, perhaps because they read the text after
"WARNING:" in
https://noncombatant.org/2015/05/01/about-http-public-key-pinning/.

If nothing else, using your own intermediate can help avoid the problems
with Google Chrome's implementation. (FWIW, Firefox's implementation also
can be coerced into behaving as badly as Chrome's, in some situations,
IIRC.)


> > My hypothesis is that CAs would be willing to start selling such
>
> certificates under reasonable terms if they weren't held responsible for
> > the things signed by such sub-CAs. It would be good to hear from CAs who
> > would be interested in that to see if that is true.
>
> That would require a change to the BRs, right? So far, no CAs have
> requested such a change, so why do you believe such CAs exist?
>

It would require changes to browsers' policies. Changing the BRs is one way
to do that, but it seems like CAB Forum is non-functional right now so it
might be better to simply route around the BRs.


> Why should a technical document be blocked on the policy document?
>

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.

Regardless, the argument for removing it is exactly your own arguments for
why you don't want to do it in Chrome. Read your own emails to learn more
about my technical objections to it.

Cheers,
Brian
-- 
https://briansmith.org/
___
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 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 what you see.
As to the latter, key pinning is viable without the use of TCSCs. It's
clear that you view there being a different risk/reward calculus for
TCSCs, but I don't think I'd agree with that calculus. Many of the
same considerations that exist with pinning EE certs still remain, and
many of the same considerations that exist with pinning CA certs still
remain.

> If draft-ietf-trans-rfc6962-bis section 4.2 discourages Mozilla from making
> externally-operated name-constrained certificates viable then please have
> somebody from Mozilla write to the TRANS list asking for section 4.2 to be
> removed from the draft.

Why, if it's completed WGLC, and describes a viable technical
mechanism that may simply not be implemented via policy until
sufficient policy controls exist?

> Go out and try to find 3 different CAs that will sell you a
> name-constrained sub-CA certificate where you maintain control of the
> private key and with no strings attached (no requirement that you implement
> the same technical controls as root CAs or being audited to the same level
> as them).

If you find a single one, do please report to this list - because
that's not permitted under the Baseline Requirements today.

> My hypothesis is that CAs would be willing to start selling such
> certificates under reasonable terms if they weren't held responsible for
> the things signed by such sub-CAs. It would be good to hear from CAs who
> would be interested in that to see if that is true.

That would require a change to the BRs, right? So far, no CAs have
requested such a change, so why do you believe such CAs exist?

> However, i do agree that the technical details
> regarding (externally-operated) name-constrained CAs in Mozilla's policy
> and in draft-ietf-trans-rfc6962-bis are insufficient, and that's why I
> support (1) removing section 4.2 from draft-ietf-trans-rfc6962-bis-20, and
> (2) improving Mozilla's policy and the BRs so that the technical details do
> become sufficient. After that we can then see if it makes sense to revise
> rfc6962-bis to add redaction based on the revised details of how root
> stores treat name-constrained externally-operated sub-CAs.

Why should a technical document be blocked on the policy document?
Shouldn't it be the other way around - or at least in parallel?
6962-bis describes a technical form, without making any statements on
when that technical form may or may not be appropriate or suitable.
That's a question of policy, much like the question of which CT logs
to accept, or how many SCTs to require, isn't it? It's unclear what
you see as technically deficient versus simply an incomplete policy
requirement.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Technically Constrained Sub-CAs

[Brian Smith]

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 "externally-operated" part would need to be policy, or a
> code-detectable marker enforced by policy, because there's no way of
> detecting that otherwise?
>

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 externally-operated sub-CAs comply with Mozilla's
technical requirements (e.g. SHA-1 deprecation and future deprecations or
transisitions).


>
> > and/or the end-entity certificates they issue
> > strictly, independently of whether it can be done for all certificates,
> and
> > doing so would be at least part of the solution to making
> name-constrained
> > externally-operated sub-CAs actually a viable alternative in the market.
>
> I'm not sure what you mean by "a viable alternative" - I thought the
> concern was to stop them proliferating,


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.


> if what's underneath them was
> opaque? And if it's not opaque,


If draft-ietf-trans-rfc6962-bis section 4.2 discourages Mozilla from making
externally-operated name-constrained certificates viable then please have
somebody from Mozilla write to the TRANS list asking for section 4.2 to be
removed from the draft.


> why are they not a viable alternative
> now, and why would restricting their capabilities make them _more_ viable?
>

Go out and try to find 3 different CAs that will sell you a
name-constrained sub-CA certificate where you maintain control of the
private key and with no strings attached (no requirement that you implement
the same technical controls as root CAs or being audited to the same level
as them). My understanding is that you won't be able to find any that will
do so, because if you go off and issue a google.com certificate then
Mozilla and others will then hold the issuing root CA responsible for that.

My hypothesis is that CAs would be willing to start selling such
certificates under reasonable terms if they weren't held responsible for
the things signed by such sub-CAs. It would be good to hear from CAs who
would be interested in that to see if that is true.

To reiterate, I disagree that the name-constraint redaction is bad because
the certificates issued by the externally-operated name-constrained CAs
must be subject to all the terms of browsers' policies, including the BRs.
That kind of thinking is 100% counter to the reason Mozilla created the
exceptions for externally-operated name-constrained CAs in its policy in
the first place. (Similarly, the requirements on externally-operated
name-constrained CAs in the baseline requirements defeat the purpose of
treating them specially.) However, i do agree that the technical details
regarding (externally-operated) name-constrained CAs in Mozilla's policy
and in draft-ietf-trans-rfc6962-bis are insufficient, and that's why I
support (1) removing section 4.2 from draft-ietf-trans-rfc6962-bis-20, and
(2) improving Mozilla's policy and the BRs so that the technical details do
become sufficient. After that we can then see if it makes sense to revise
rfc6962-bis to add redaction based on the revised details of how root
stores treat name-constrained externally-operated sub-CAs.

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

Mozilla CT Policy: discussion location

[Gervase Markham]

mozilla.dev.security.policy has become the /de facto/ place for
discussion root program policy relating to the Web PKI, not just for
Mozilla, because people want to take advantage of the expertise of the
members here. Mozilla is very happy to host these wider discussions, in
the name of making the Internet and the Web PKI a more secure and
better-functioning place.

Similarly, ct-pol...@chromium.org has so far been the place for
discussing CT policy. Ryan has kindly offered to permit Mozilla to have
our CT policy discussions on that list, taking advantage of the
expertise there.

So, I have drafted a version 0.0.1 of the Mozilla CT policy, and will
soon post it to ct-pol...@chromium.org. If you want to be part of that
conversation, you will need to subscribe, which you can do here:
https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy

I am unfortunately not aware of an NNTP mirror of this group, and Gmane
is currently in a transition which means that adding new groups is not
supported. If anyone knows of such a mirror, please let me know.

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

[Rob Stradling]

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 Google's position that it is OK to leave bad stuff in
the spec and then ignore it. The WGLC has passed, but that doesn't mean
that the spec can't be changed. Google's already proposed a hugely
significant change to the spec in the last few days (which I support),
which demonstrates this.

Accordingly, I think the exception mechanism for name-constrained sub-CAs
(section 4.2) should be removed from the spec. This is especially the case
if there are no browsers who want to implement it. If the draft contains
things that clients won't implement, then that's an issue that's relevant
for the IETF last call, as that's against the general IETF philosophy of
requiring running code.


Brian, please consider sending your comments to TRANS.

FWIW, after Ryan Sleevi publicly stated that Chrome won't be supporting 
this exception mechanism as currently specified in 6962-bis, I attempted 
(without success) to obtain approval to move it out of 6962-bis and into 
draft-strad-trans-redaction.


Maybe if there are more people saying the same thing...

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

[Gervase Markham]

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 policy, or a
code-detectable marker enforced by policy, because there's no way of
detecting that otherwise?

> and/or the end-entity certificates they issue
> strictly, independently of whether it can be done for all certificates, and
> doing so would be at least part of the solution to making name-constrained
> externally-operated sub-CAs actually a viable alternative in the market.

I'm not sure what you mean by "a viable alternative" - I thought the
concern was to stop them proliferating, if what's underneath them was
opaque? And if it's not opaque, why are they not a viable alternative
now, and why would restricting their capabilities make them _more_ viable?

Sorry to be lost,

Gerv

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