RE: Name issues in public certificates

[Robin Alden]

Peter said..
> While I realize that it is not clear cut in many contexts, RFC 5280 is
> rather clear cut.  The authors clearly wanted to avoid stumbling and
> being eaten by a grue, so they wrote:
> 
>When the subjectAltName extension contains a domain name system
>label, the domain name MUST be stored in the 
>dNSName (an IA5String).
>The name MUST be in the "preferred name syntax", as specified by
>Section 3.5 of [RFC1034] and as modified by Section 2.1 of
>[RFC1123].  
> 
> This makes it clear that the "preferred name syntax" is not a
> recommendation when it comes to certificates.  It is mandatory.

Ah, but the lead-in there is 
"When the subjectAltName extension 
contains a domain name system label,"

weird_place.example.com is not a domain name system label.  It is not
expected to (and likely does not, and maybe could not) resolve to an IP
address on the public internet.

In practice, the people to whom weird_place.example.com is a useful name
will be running Microsoft kit which is very happy with an underscore in
a name.  All that matters to them is that weird_place.example.com
resolves within their environment.
The CAB Forum BRs can be met in the validation of such a certificate
providing that ownership or control of example.com is shown in the
approved methods.  The BRs place no requirement on the full name
weird_place.example.com appearing on the internet or being accessible by
the CA.

Regards
Robin



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: Certum Root Renewal Request

[arkadiusz . lawniczak]

Hi

We've provided code signing certificates to our customers for many years. Also, 
at this time, the new root CTNCA 2 is going to be used for this purpose. 
When it comes to a specific group of customers, I would say it appears that we 
don't have customers who need to use our root from NSS root store for code 
signing purposes. Tt is possible that they exist but we do not know anything 
about it.

Therefore, we are not opposed to the removal of trust bits from our and other 
root certificates.

Yours Sincerely

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

Policy Update Proposal: Require full CP/CPS in English

[Kathleen Wilson]

I would like to discuss this proposal[1] next:

- (D26) Add a requirement for CAs to provide English-translated versions 
of their complete CP / CPS


I think we would have to narrow it down a bit, because some CAs have 
several CP/CPS documents for their various product offerings, not 
related to SSL or S/MIME certs.


So, how about if we add a bullet point to section 6 of the Inclusion 
policy, which currently starts as follows.

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
~~
6. We require that all CAs whose certificates are distributed with our 
software products:

- provide some service relevant to typical users of our software products;
- publicly disclose information about their policies and business 
practices (e.g., in a Certificate Policy and Certification Practice 
Statement);

~~

Insert 3rd bullet point:
"- translate into English the Certificate Policy and Certification 
Practice Statement documents pertaining to the certificates to be 
included and the trust bits to be enabled;"


I will appreciate recommendations about how to improve this proposed update.

Is this a reasonable requirement to add?

Are there any arguments against adding this requirement that we should 
consider?



Thanks,
Kathleen

[1] https://wiki.mozilla.org/CA:CertificatePolicyV2.3

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

Re: Name issues in public certificates

[Peter Bowen]

On Thu, Nov 19, 2015 at 4:26 PM, Brian Smith  wrote:
> Peter Bowen  wrote:
>>
>> Robin Alden  wrote:
>> Given that it doesn't, but that that the BRs say "MUST be either a
>> dNSName containing the Fully‐Qualified Domain Name or an iPAddress
>> containing the IP address", it is clear we still need to have a valid
>> FQDN.  I'll update my scanner to allow "_" in the labels that are not
>> registry controlled or in the label that is immediately to the left of
>> the registry controlled labels.  Give me a little while and I'll
>> upload a revised data set with this fix.
>
>
> See https://bugzilla.mozilla.org/show_bug.cgi?id=1136616. In mozilla::pkix,
> we had to allow the underscore because of AWS.

Touche :)  It looks like S3 allows underscores but calls out that they
are not DNS compliant
(http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html).
People accessing these buckets should be using the
https://s3.amazonaws.com/$BUCKET/$KEY URL format, not the
https://$BUCKET.s3.amazonaws.com/$KEY URL format.   I will talk to the
S3 team about ensuring that all names published in DNS are compliant
with RFC 1123.

That being said, I updated the spreadsheet to allow underscores in
both the CN and dNSName generalName.  Please note that the updated
sheet has a slightly different column order.  I also added rules to
check for nulls in dNSNames (one hit), unparsable ASN.1 in the
subjectAltName extension (23 hits), and basic validation for
RFC822Names in SANs (even though they are not allowed in by the BRs).

The sheet is available at:
https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing

As always, I welcome feedback.

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

Re: Certum Root Renewal Request

[Kathleen Wilson]

On 10/21/15 12:28 PM, Kathleen Wilson wrote:

On 10/1/15 3:44 PM, Kathleen Wilson wrote:

Unizeto Certum has applied to include the “Certum Trusted Network CA 2”
root certificate, turn on all three trust bits, and enable EV treatment.
This is the next generation of the “Certum Trusted Network CA” root cert
that was included via bug #532377.



Does anyone have any comments, questions, or concerns about this request
from Unizeto Certum?

Kathleen




Are there any further comments on this request, or is it OK to proceed 
with recommending approve with the caveat that we are no longer turning 
on the code signing trust bit for roots?


Thanks,
Kathleen

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

Re: Name issues in public certificates

[Peter Bowen]

On Thu, Nov 19, 2015 at 11:57 AM, Robin Alden  wrote:
> Peter said..
>> While I realize that it is not clear cut in many contexts, RFC 5280 is
>> rather clear cut.  The authors clearly wanted to avoid stumbling and
>> being eaten by a grue, so they wrote:
>>
>>When the subjectAltName extension contains a domain name system
>>label, the domain name MUST be stored in the
>>dNSName (an IA5String).
>>The name MUST be in the "preferred name syntax", as specified by
>>Section 3.5 of [RFC1034] and as modified by Section 2.1 of
>>[RFC1123].  
>>
>> This makes it clear that the "preferred name syntax" is not a
>> recommendation when it comes to certificates.  It is mandatory.
>
> Ah, but the lead-in there is
> "When the subjectAltName extension
> contains a domain name system label,"
>
> weird_place.example.com is not a domain name system label.  It is not
> expected to (and likely does not, and maybe could not) resolve to an IP
> address on the public internet.

Yes, reading again I agree that the language there leaves it open that
the dNSName type might not contain a domain name system label.  If the
authors truly wanted to avoid the grue, they should have said:

"When the subjectAltName extension contains a dNSName, the dNSName
must contain a domain name." (or domain name system label).

Given that it doesn't, but that that the BRs say "MUST be either a
dNSName containing the Fully‐Qualified Domain Name or an iPAddress
containing the IP address", it is clear we still need to have a valid
FQDN.  I'll update my scanner to allow "_" in the labels that are not
registry controlled or in the label that is immediately to the left of
the registry controlled labels.  Give me a little while and I'll
upload a revised data set with this fix.

> In practice, the people to whom weird_place.example.com is a useful name
> will be running Microsoft kit which is very happy with an underscore in
> a name.  All that matters to them is that weird_place.example.com
> resolves within their environment.
> The CAB Forum BRs can be met in the validation of such a certificate
> providing that ownership or control of example.com is shown in the
> approved methods.  The BRs place no requirement on the full name
> weird_place.example.com appearing on the internet or being accessible by
> the CA.

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

Re: Policy Update Proposal: Require full CP/CPS in English

[Matt Palmer]

On Thu, Nov 19, 2015 at 05:00:03PM -0800, Kathleen Wilson wrote:
> Insert 3rd bullet point:
> "- translate into English the Certificate Policy and Certification Practice
> Statement documents pertaining to the certificates to be included and the
> trust bits to be enabled;"
> 
> I will appreciate recommendations about how to improve this proposed update.

Some wording to require CAs to acknowledge that this translation is not
merely informative, but in fact a binding agreement with the Internet
community, would be useful.  I can easily imagine a CA claiming, in the
event of a breach of the CPS, that the "authoritative" version, in an
alternate language, doesn't describe things in quite the same way, and so
isn't a breach.

> Is this a reasonable requirement to add?

I think it is.  The working language of the technical Internet (and this
list) is, for better or worse, English, and ensuring that the core
documentation of a CA's agreement with the Internet community is consumable
by the largest possible number of interested parties is an important goal.

- Matt

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

Re: SECOM Request for EV Treatment

[h-kamo]

2015年11月13日金曜日 23時27分46秒 UTC+9 Kathleen Wilson:
> On 11/13/15 5:43 AM, Peter Kurrasch wrote:
> > Kathleen, is SECOM getting special treatment? I was wondering if there was 
> > some reason to move forward before a CA has everything in order? Will we be 
> > seeing more of this going forward?
> >
> 
> I thought everything was in order, except perhaps there might be a few 
> more suggestions to updating their CPS that could be tracked in parallel 
> (i.e. not show stoppers). We have done that in the past, and Ryan had 
> sent me email saying that he might not be able to participate in the 
> inclusion review discussions for a while, so to go forward without him.
> 
> But as you can see in the bug I realized that was not quite the case 
> when I went to write the summary to recommend approval. So, in the bug I 
> clarified that SECOM needs to make further updates to their CP/CPS 
> before we can move forward.
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1096205#c28
> 
> So, it was not intentional.
> 
> However, I would like to get the root inclusion/update discussions 
> moving forward again -- those discussions have stalled out.
> 
> Kathleen


Dear Kathleen-san,

The updated CP for detailed descrition(the certificate subscriber 
owns/controls) about domain verification for the section 3.2.7 is attached on 
bugzilla.
https://bugzilla.mozilla.org/attachment.cgi?id=8689921
Email address verification does not apply to this EV SSL CP/CPS.

The corresponding section were made comprehensible by blue characters. 

Thank you for your consideration.

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

Re: Name issues in public certificates

[Patrick T]

On Tuesday, 17 November 2015 08:04:41 UTC, Peter Bowen  wrote:
> Inspired by Rob Stradling's work
> (https://cabforum.org/pipermail/public/2015-November/006269.html), I
> wrote a quick tool to check that commonNames and Subject Alternative
> Names in server auth certificates issued by public CAs were following
> the CA/Browser Forum baseline requirements.
> 
> The resulting report of anomalies is available at
> https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing
> 
> The rules are a rather strict interpretation of RFC 5280 and the
> Baseline Requirements.  Notably, it will complain if FQDNs are not
> converted to ASCII (as defined in 7.2 and 7.3 of RFC 5280) and will
> complain if there is an IP address flaged as a dNSName in a
> Generalized Name.
> 
> There are a couple of rules that may create false positives, so please
> don't assume every certificate on the sheet is problematic.
> 
> Thanks,
> Peter

I've found one of the certificates here (*.gov.bn, Symantec issued) seems to 
contain some NULL characters in the SAN.

https://crt.sh/?serial=331C896050CE23EFAB5CF53237AF093F
and
https://crt.sh/?id=7335256

Wasn't there an issue with spoofing using NULs in certificates several years 
ago?
Verisign back then claimed this couldn't be done, but the cert is recent.

http://www.symantec.com/connect/blogs/busy-day-black-hat
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy