Re: Remove Roots used for only Email and CodeSigning?

2015-09-18 Thread Gervase Markham 
On 18/09/15 09:55, Rob Stradling wrote:
> But since there are no current plans to change Thunderbird...
> Does this mean that Thunderbird still has a use for code signing
> certificates from commercial CAs and, consequently, the NSS code signing
> trust bit?

That would be a question for the Thunderbird team. Their mailing list is
tb-planning:
https://mail.mozilla.org/listinfo/tb-planning

Gerv

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

Re: Remove Roots used for only Email and CodeSigning?

2015-09-18 Thread Rob Stradling 
On 17/09/15 12:19, Rob Stradling wrote:
> On 15/09/15 10:17, Gervase Markham wrote:
>> On 11/09/15 22:06, Rob Stradling wrote:
>>> On 11/09/15 13:05, Gervase Markham wrote:
 On 08/09/15 10:54, Rob Stradling wrote:
> Assuming this is still Mozilla's plan, please would you clarify which
> versions of Firefox and Thunderbird will be (or were?) the first
> versions that won't accept "normal CA-issued object-signing certificates" 
> ?

 Extension signing was historically very rare, so I'm not sure what our
 new signing system would do when faced with an extension which is
 already signed. (Is that what you are asking?)
>>>
>>> Yes, that's what I'm asking.
>>
>> I would ask Jorge Villalobos, perhaps in the group
>> mozilla.addons.user-experience:
>> https://www.mozilla.org/en-US/about/forums/#addons-user-experience
> 
> Thanks Gerv.
> 
> I've posted a comment (currently awaiting moderation) here:
> https://blog.mozilla.org/addons/2015/09/16/extending-the-deadline-for-add-on-signing/
> 
> (Not sure I can face joining Yet Another Newsgroup!)

Gerv, Kathleen,

Jorge replied [1]:
"The new signing system removes the existing signature, since there can
only be one. For the moment this should only affect Firefox. There are
no current plans to require signatures on Thunderbird."

So it's clear that, for Firefox, code signing certificates from
commercial CAs will cease to be useful once the new extension signing
requirement comes into effect.

But since there are no current plans to change Thunderbird...
Does this mean that Thunderbird still has a use for code signing
certificates from commercial CAs and, consequently, the NSS code signing
trust bit?


[1]
https://blog.mozilla.org/addons/2015/09/16/extending-the-deadline-for-add-on-signing/comment-page-1/#comment-219722

-- 
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: Firefox security too strict (HSTS?)?

2015-09-18 Thread Anil G 
> > To make my point again, I can't access https://input.mozilla.org/en-US/ 
> > from Firefox, I have to use Chrome.
> In Chrome, navigate to https://input.mozilla.org/en-US/ 
>  and then click the green lock.  Click on 
> the "Connection" tab then cut and paste the first couple of sentences.
> Thanks,
> Peter

With thanks to Yuhong Bao and Peter Gutman, yes, I am behind enterprise network 
behaving like MITM, but that's my point. I've only recently just supported IT 
to correct MITM cert distribution and we still have issues like this. But none 
of these issues affected Chrome. Chrome works for enterprise out of the box.

With thanks to Peter Bowen, answers below, but please note I'm not asking this 
forum to fix my Firefox. I'm suggesting that there may be a long term problem 
for Firefox not operating easily enough to prevent it getting excluded from 
enterprises and homes just on this basis alone.

At https://input.mozilla.org/en-US/ Chrome says "The identity of Mozilla 
Foundation at Mountain View, California US has been verified by DigiCert SHA2 
Extended Validation Server CA. Valid Certificate Transparency information was 
supplied by the server." and "Your connection to input.mozilla.org is encrypted 
using a modern cipher suite. The connection uses TLS 1.2. The connection is 
encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key 
exchange mechanism."

After I re-tried in Firefox, after a delay of a few minutes, it eventually 
shows the page. Firefox is showing the page now. But originally attempting the 
URI gives the message I shared, and continuous to give it even when pushing 
hard refreshes a few times.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Policy Update Proposal: Remove Code Signing Trust Bit

2015-09-18 Thread Peter Kurrasch 
Hi Kathleen, 

This summary looks pretty good. I think you could add the point raised by Man 
Ho which essentially asks the question of who should/can/will evaluate the 
trustworthiness of root certs. There are pros and cons either way on that one.

One last comment I'll make is that, among other things, I've been approaching 
this from the standpoint of Mozilla's commitment to openness, open-souce, and 
security. Perhaps that's a bit rosy but I'll offer it up for whatever it may be 
worth.

Thanks.

  Original Message  
From: Kathleen Wilson
Sent: Thursday, September 17, 2015 6:26 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy Update Proposal: Remove Code Signing Trust Bit

Thanks to all of you for your thoughtful and constructive input in this 
discussion.

Here is a summary of this discussion so far.

Proposal: Remove references to code signing from Mozilla's CA 
Certificate Policy, then turn off all Code Signing trust bits for root 
certificates included in the NSS root store. This essentially means that 
Mozilla will stop saying that root certificates in the NSS root store 
can be trusted for code signing.

Arguments against this proposal:
- Code signing is very important in the embedded space
- Removing the code signing trust bit sends a message that Mozilla does 
not want to (and will not) participate in this space
- The loss of Mozilla’s support could be a setback to the embedded 
space; i.e. innovation in embedded software could suffer.
- We should not presume that the embedded space is any more amenable to 
a one-size-fits-all solution any more than the SSL space is.


Arguments for this proposal:
- The only situation in which this change will impact an embedded vendor 
is if they allow anyone with a public (i.e. chaining to a root cert in 
NSS) code-signing certificate to run code on their device.
- A public (i.e. chaining to a root cert in NSS) code-signing cert is 
basically a cert that identifies an individual or organization. This 
alone is insufficient for a manufacturer to decide to embed another 
vendor's software in their products.
- If a manufacturer has a direct relationship with the vendors of the 
software they embed, then they can directly trust code-signing 
certificates provided by the vendor, and not rely on the certificates 
chaining up to a root cert in the NSS root store.
- The manufacturer should maintain their own trust list, and not shift 
the responsibility to Mozilla purely because they used the NSS root 
store in their system.
- Mozilla already requires that all plugins be signed by Mozilla, so 
Mozilla is not depending on the NSS root store for code-signing purposes.
- Mozilla currently does not have robust policies around verifying the 
acceptability of root certificates for the purposes of code signing.
- Building a properly run code signing certificate program would be a 
ton of work that Mozilla has never done, and is not prepared to do.
- If the decision makers are not well versed in the use cases behind 
code signing, then they should not be making decisions regarding root 
inclusion/exclusion for code signing.


Other:
- If the decision were made to proceed with the removal of the code 
signing trust bit, Mozilla would need to broadly publicize the change, 
as there may be smaller consumers of these capabilities who will need to 
explore other solutions.


Please let me know if I missed anything or misrepresented any of your 
input.

Is there any other input/feedback we should consider?

Thanks,
Kathleen


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

Re: Firefox security too strict (HSTS?)?

2015-09-18 Thread Eric Mill 
Small note, to correct a misunderstanding from earlier in the thread --
even if *.mozilla.org were doing key pinning, Chromium/Chrome will ignore
key pins if the observed cert chains up to a user/enterprise-installed
root. So that wouldn't cause any issues.

-- Eric

On Fri, Sep 18, 2015 at 12:06 AM, Yuhong Bao 
wrote:

> >> On Sep 17, 2015, at 8:29 PM, AnilG  wrote:
> >>
> >> On Friday, 18 September 2015 12:29:46 UTC+10, Peter Gutmann wrote:
> >>> base. If you look at Mozilla's own figures at
> >>> https://input.mozilla.org/en-US/, they have a 90% dissatisfaction
> rating from
> >>
> >> To make my point again, I can't access https://input.mozilla.org/en-US/
> from Firefox, I have to use Chrome.
> >
> > Can you do a quick test to help understand the likely root cause of your
> issue?
> >
> > In Chrome, navigate to https://input.mozilla.org/en-US/ <
> https://input.mozilla.org/en-US/> and then click the green lock. Click on
> the “Connection” tab then cut and paste the first couple of sentences.
> >
> > It should say something like “The identity of […] has been verified by
> […]. […] information was supplied by the server.”
> >
> > That will help determine what is causing your problem.
>
> Also see if it has something about TLS version fallback. Chrome is still
> doing TLS 1.1 version fallback and it might be hiding the problem at the
> MITM.
> ___
> 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