Re: Name issues in public certificates

[Matthias Hunstock]

Am 09.12.2015 um 18:46 schrieb Peter Bowen:

> Do you have an example where you think IPv6 addresses are not being
> handled correctly?

Serial 19D70E1B381579 in your document is the example I stumbled upon.

I managed to get the complete cert from the server and cannot see any
issues there.

It is flagged as "_unqualified" though it has a global unicast IPv6
address, beside other SubjectAlternativeNames.


Regards
Matthias

___
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, Dec 10, 2015 at 6:07 AM, Matthias Hunstock  wrote:
> Am 09.12.2015 um 18:46 schrieb Peter Bowen:
>
>> Do you have an example where you think IPv6 addresses are not being
>> handled correctly?
>
> Serial 19D70E1B381579 in your document is the example I stumbled upon.
>
> I managed to get the complete cert from the server and cannot see any
> issues there.
>
> It is flagged as "_unqualified" though it has a global unicast IPv6
> address, beside other SubjectAlternativeNames.

You are correct.  There is a logic bug and it is flagging properly
encoded ipv6 addresses in the SAN as unqualified. There are 9
certificates in CT that have IPv6 addresses.

Apologies for this.  I will get the tool updated to ensure that IPv6
addresses do not cause a flag.  For now, however, please ignore any
"unqualified" result for a SAN:IP row.  This rule should be impossible
to hit for that data type.

Thanks,
Peter
___
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

[Matthias Hunstock]

Am 10.12.2015 um 15:47 schrieb Peter Bowen:
> Apologies for this.  I will get the tool updated to ensure that IPv6
> addresses do not cause a flag. 

Thank you for fixing this!

Matthias
___
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 Wed, Dec 9, 2015 at 9:35 AM, Matthias Hunstock  wrote:
> Am 17.11.2015 um 09:04 schrieb Peter Bowen:
>
>> There are a couple of rules that may create false positives, so please
>> don't assume every certificate on the sheet is problematic.
>
> Is it possible that your script doesn't handle IPv6 addresses properly?

It should handle IPv6 addresses correctly when they are presented in
the SAN using the IPAddress type.  It would currently flag IPv6
addresses in the common name as issues, but I did a manual check and
found no certificates with IPv6 addresses in the common name.

Do you have an example where you think IPv6 addresses are not being
handled correctly?

Thanks,
Peter
___
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

[Matthias Hunstock]

Am 17.11.2015 um 09:04 schrieb Peter Bowen:

> There are a couple of rules that may create false positives, so please
> don't assume every certificate on the sheet is problematic.

Is it possible that your script doesn't handle IPv6 addresses properly?


Regards


___
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

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