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-
> [email protected]] On Behalf Of
Brian
> Smith
> Sent: 24 August 2015 18:12
> To: Gervase Markham <[email protected]>
> Cc: [email protected]
> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
