RE: Updating Mozilla's CA Certificate Policy

[Steve Roylance]

Hi Brian,

Apologies for the delay in responding as I was on vacation at the end of
last week.  The answer for GlobalSign  (and I suspect some of the other
CA's) to the pathLengthConstraint questions should be that we are compliant
for 2 and 3.
I blame my lack of knowledge on this attribute at an ASN1 level as my
'check'  was done using the cert viewer in Windows which was not helpful.

For the EV Certificate on www.globalsign.com

ASN1
SEQUENCE(2 elem)
  OBJECT IDENTIFIER2.5.29.19
OCTET STRING(1 elem)
SEQUENCE(0 elem)

Windows Cert viewer
Subject Type=End Entity
Path Length Constraint=None

Kathleen,

Can I remove my responses to (2) and (3) and leave the response in for (10)
for now.  How do I do this?

Please note for point 10, that if you encode domain component into any
certificate (For example Name Constraints, or end entities via a popular
commercially available CA) then these must be IA5 as per RFC "7.3.
Internationalized Domain Names in Distinguished Names".  We've seen issues
with forcing these to printable string in recent weeks on CISCO devices.
I'll see if one of our engineers can add some details to the bug to qualify
this.

Apologies for the confusion.

Steve

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve.roylance=globalsign@lists.mozilla.org] On Behalf Of
Brian
> Smith
> Sent: 24 August 2015 18:12
> To: Gervase Markham 
> Cc: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Updating Mozilla's CA Certificate Policy

[Steve Roylance]
> 1. Mozilla recently asked some CAs about their practices in issuing
certificates
> that are syntactically invalid in various ways, and we got a lot of good
responses
> [1]. I was struck by the responses like GlobalSign's that basically said,
> paraphrasing, "we intend to continue knowingly violate the baseline
requirements
> by issuing syntactically invalid certificates." I think it would be good
to make it
> clearer that producing syntactically valid certificates is **required**.
In particular, I
> think that Mozilla should audit a CA's recently-issued certificates and
> automatically reject a CA's request for inclusion or membership renewal if
there
> are a non-trivial number of certificates that have the problems mentioned
in [2].
> (Also, I have some new information about problematic practices to expand
the list
> in [2], which I hope to share next week.)


smime.p7s
Description: S/MIME cryptographic signature
___
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?

[Kurt Roeckx]

On 2015-09-03 20:22, Kathleen Wilson wrote:

2) Remove included root certs that only have the Code Signing trust bit
enabled. To our knowledge, no one is using such root certs via the NSS
root store.


I'm wondering how you currently support things like java applets.  As 
far as I understand for some activity of them you need to have them 
signed.  Is this handled by the java plugin itself?  Where does it get 
it's root store from?



Kurt

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

[Hubert Kario]

On Thursday 03 September 2015 11:22:26 Kathleen Wilson wrote:
> 2) Remove included root certs that only have the Code Signing trust
> bit enabled. To our knowledge, no one is using such root certs via
> the NSS root store.

I'm not familiar with the project, but Fedora Shared System 
Certificates[1] does use Mozilla Root list and it does encompass Java 
trust stores so Code Signing bits at the very least _should_ be used, if 
not already are used.

 1 - https://fedoraproject.org/wiki/Features/SharedSystemCertificates

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
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?

[Richard Barnes]

On Fri, Sep 4, 2015 at 4:53 AM, Gervase Markham  wrote:

> On 03/09/15 19:22, Kathleen Wilson wrote:
> > 2) Remove included root certs that only have the Code Signing trust bit
> > enabled. To our knowledge, no one is using such root certs via the NSS
> > root store.
>
> This seems like a half-way house. If no-one is using our root store as a
> code-signing root store, we should stop supporting the code-signing bit
> entirely, remove the bit from all roots, and remove the UI associated
> with it in all apps.
>


I would personally be OK with that, since I'm pretty sure there's nothing
in the Mozilla code base that makes use of that trust bit.  (All of the
code signing the Firefox does is under hard-coded Mozilla-owned roots.)
The questions of removing the bit entirely or removing UI, however, are for
the NSS team and dev.tech.crypto, respectively.

It does make sense for this group to opine on removing the code signing bit
from all roots.  If we agree to remove the code-signing-only roots, then
removing the code-signing bit from other roots seems like an obvious
additional step to me.

--Richard




> But if we still want to support the code-signing use case, we shouldn't
> remove these roots.
>
> Gerv
> ___
> 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