Re: [FORGED] Name issues in public certificates

[Peter Bowen]

On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling  wrote:
> I would also like to get clarification on if/when the underscore character
> may be used in each of the name types.  Your report seems to flag
> underscores as always prohibited (I think), but I expect that some CAs would
> be surprised by that.

Here is a set of rules that are functionally equivalent to the ones
I'm using to check dNSNames in GeneralNames:

LABEL = "((?!-)[A-Za-z0-9-]{1,63}(?https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Name issues in public certificates

[Ryan Sleevi]

On Wed, November 18, 2015 8:56 am, Peter Bowen wrote:
>  On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling 
>  wrote:
> > I would also like to get clarification on if/when the underscore
> > character
> > may be used in each of the name types.  Your report seems to flag
> > underscores as always prohibited (I think), but I expect that some CAs
> > would
> > be surprised by that.
>
>  Here is a set of rules that are functionally equivalent to the ones
>  I'm using to check dNSNames in GeneralNames:
>
>  LABEL = "((?!-)[A-Za-z0-9-]{1,63}(?  FQDN = "(#{LABEL}\.)*#{LABEL}"
>  WILDCARD_DN = "\\*\\.#{FQDN}"
>  DNSNAME = "(#{FQDN}|#{WILDCARD_DN})"
>
>  dNSName =~ /\A#{DNSNAME}\z/
>
>  The FQDN rule is based on RFC 5280 section 4.2.1.6, which in turn
>  references RFCs 1123 and 1034.  There is no allowance for underscores
>  in domain names in these RFCs.
>
>  Thanks,
>  Peter

You've entered a special hell. It is dark and scary. You are likely to be
eaten by a grue.

The world is an awful place. Hostnames, doubly so. A big part of this is
due to how MSFT originally implemented their resolver code, although
arguably it can affect non-MSFT platforms as well, depending on the name
server setup.

Recall that DNS labels are full 8-bit, however, for practical purposes
(read: compatability), it's best to treat them as 7-bit ASCII. This is
somewhat touched upon in 1034 ("By convention, domain names can be stored
with arbitrary case ...") and in 1123 ("The DNS defines domain name syntax
very generally -- a string of labels each containing up to 63 8-bit
octets")

Terminology wise, let's call those "labels". A series of labels,
terminated by the empty label, make up a domain name. One type of domain
name is the host name (c.f. 1034, "For hosts, the mapping depends on the
existing syntax for host names which is a subset of the usual text
representation for domain names"), which corresponds to the A domain
record type (or , as later modified by the IPv6 specs)

OK, so we're clear so far? Recap is:
label = 0-63 octets
domain name = a series of labels, terminated by an empty label, not to
exceed 255 octets (counting label lengths as well)
host name = a subset of types of domain names, that in DNS corresponds to
the A/ record

Now let's get messier yet still. 1034 introduces the "Preferred Name
Syntax", which is a recommendation for how to encode names. For example,
one part is that it suggests that all labels start with at least one
letter. This is to avoid ambiguity when parsing IPs, since if labels could
be all numeric (10.0.0.1), then it could be ambiguous as to how to parse
as a host name versus an IP address. However, 1123, Section 2.1, relaxed
this to allow the first character to be a digit, on the presumption that
all TLDs would be alpha-numeric.

This latter point wasn't enshrined anywhere, as far as I've been able to
tell, but was practiced by the set of gTLDs at the time and continues to
be practiced by ICANN (thus far).

So, now, the question is, where do the '_' come from?

Two places:
1) The URI spec (RFC 2396) permitted them because it didn't couple a URL
to the underlying name resolution system (DNS), but instead permitted a
variety of name and name resolution schemes. The ABNF from this spec
diverged from 1123, and 3986 tried to bring alignment again, but the
'damage' of permissiveness was done.
2) Microsoft's host resolution API, which supported a variety of name
types (DNS, NetBios, WINS, etc), in which the incoming string was looked
up against a variety of name resolution services. Their DNS resolver
adhered to the '8 bit is good bit' and '7 bit ASCII is good', and thus let
it through.

Further, it's important to consider that _ are valid (domain) names, and
ARE valid (URL host) names, even if they're not valid (DNS host) names.
Consider, for example, SRV names.

You hate everything yet? Because I sure do.

I captured some of these thoughts in
https://code.google.com/p/chromium/issues/detail?id=496472 and
https://code.google.com/p/chromium/issues/detail?id=496468 just because no
browser I've looked at 'does the right thing' and rejects underscores.

I mention all of this to say that I actually find it 'not clear cut' as to
what's expected, and have spent several day long dives into specs and
other implementations to see if there's any common consistency, especially
for https://url.spec.whatwg.org/ . On a pragmatic level, I'd like to be a
hard liner, with being one clear interpretation, but in the real world, I
can't find anyone who consistently followed or implemented that guidance.

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

Work-in-Progress Version 2.3 of Mozilla CA Cert Policy

[Kathleen Wilson]

All,

The work-in-progress for version 2.3 of Mozilla's CA Certificate Policy 
is in github:


master repo: https://github.com/mozilla/ca-policy

The changes made so far are listed here:
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Changes_Made_to_DRAFT_Version_2.3

Additionally, the policy has been converted to Markdown.

To see what the updated policy looks like so far:
http://mozilla.github.io/ca-policy/

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

Re: Policy Update Proposal -- Refer to BRs for Name Constraints Requirement

[Kathleen Wilson]

On 11/5/15 11:00 AM, Kathleen Wilson wrote:

On 10/28/15 10:25 AM, Kathleen Wilson wrote:


Therefore, this proposal is modified to simplify item #9 of the
Inclusion Policy,
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/


as follows:
~~
We encourage CAs to technically constrain all subordinate CA
certificates. For a certificate to be considered technically
constrained, the certificate MUST include an Extended Key Usage (EKU)
extension specifying all extended key usages that the subordinate CA is
authorized to issue certificates for. The anyExtendedKeyUsage
KeyPurposeId MUST NOT appear within this extension.
- If the certificate includes the id-kp-serverAuth extended key usage,
then the certificate must be Name Constrained as described in section
7.1.5 of version 1.3 or later of the CA/Browser Forum Baseline
Requirements for the Issuance and Management of Publicly-Trusted
Certificates.
- If the certificate includes the id-kp-emailProtection extended key
usage, then all end-entity certificates MUST only include e-mail
addresses or mailboxes that the issuing CA has confirmed (via technical
and/or business controls) that the subordinate CA is authorized to use.
~~




Based on the lack of response to this revised proposal, I am going to
assume that everyone is OK with it.  Please let me know if you disagree.

Thanks,
Kathleen




I've moved this proposal to the Approved section in the wiki page:
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Approved

Thanks,
Kathleen


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

Re: [FORGED] Name issues in public certificates

[Peter Bowen]

On Wed, Nov 18, 2015 at 10:25 AM, Ryan Sleevi
 wrote:
> On Wed, November 18, 2015 8:56 am, Peter Bowen wrote:
>>  On Wed, Nov 18, 2015 at 2:22 AM, Rob Stradling 
>>  wrote:
>> > I would also like to get clarification on if/when the underscore
>> > character
>> > may be used in each of the name types.  Your report seems to flag
>> > underscores as always prohibited (I think), but I expect that some CAs
>> > would
>> > be surprised by that.
>>
>>  Here is a set of rules that are functionally equivalent to the ones
>>  I'm using to check dNSNames in GeneralNames:
>>
>>  LABEL = "((?!-)[A-Za-z0-9-]{1,63}(?>  FQDN = "(#{LABEL}\.)*#{LABEL}"
>>  WILDCARD_DN = "\\*\\.#{FQDN}"
>>  DNSNAME = "(#{FQDN}|#{WILDCARD_DN})"
>>
>>  dNSName =~ /\A#{DNSNAME}\z/
>>
>>  The FQDN rule is based on RFC 5280 section 4.2.1.6, which in turn
>>  references RFCs 1123 and 1034.  There is no allowance for underscores
>>  in domain names in these RFCs.
>
> You've entered a special hell. It is dark and scary. You are likely to be
> eaten by a grue.
>
> The world is an awful place. Hostnames, doubly so.
[...]

> Now let's get messier yet still. 1034 introduces the "Preferred Name
> Syntax", which is a recommendation for how to encode names. For example,
> one part is that it suggests that all labels start with at least one
> letter. This is to avoid ambiguity when parsing IPs, since if labels could
> be all numeric (10.0.0.1), then it could be ambiguous as to how to parse
> as a host name versus an IP address. However, 1123, Section 2.1, relaxed
> this to allow the first character to be a digit, on the presumption that
> all TLDs would be alpha-numeric.
[...]

> I mention all of this to say that I actually find it 'not clear cut' as to
> what's expected, and have spent several day long dives into specs and
> other implementations to see if there's any common consistency

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].  Note that while uppercase and lowercase letters are
   allowed in domain names, no significance is attached to the case.  In
   addition, while the string " " is a legal domain name, subjectAltName
   extensions with a dNSName of " " MUST NOT be used.  Finally, the use
   of the DNS representation for Internet mail addresses
   (subscriber.example.com instead of subscri...@example.com) MUST NOT
   be used; such identities are to be encoded as rfc822Name.

This makes it clear that the "preferred name syntax" is not a
recommendation when it comes to certificates.  It is mandatory.

The CA/Browser Forum already has changed the rules for the CAB Forum
X.509 profile to allow dNSName entries to contain "*" which is
contrary to RFC 5280, so maybe the forum should consider other
variations of the rules of 5280.

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

RE: [FORGED] Name issues in public certificates

[Richard Wang]

We tested IE11, Firefox 42, Chrome 45 on Windows 10, all support IP address 
only now.
So we need to test the old version browsers. I will update soon.


Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Richard Wang
Sent: Wednesday, November 18, 2015 10:41 AM
To: Peter Bowen 
Cc: Rob Stradling ; 
mozilla-dev-security-pol...@lists.mozilla.org; Peter Gutmann 

Subject: RE: [FORGED] Name issues in public certificates

Yes, all Client certificates are removed, thanks.

So WoSign only left IP address issue that we added both IP address and DNS 
Name since some browser have warning for IP address only in SAN.


Best Regards,

Richard


-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Wednesday, November 18, 2015 10:28 AM
To: Richard Wang 
Cc: Rob Stradling ;
mozilla-dev-security-pol...@lists.mozilla.org; Peter Gutmann

Subject: Re: [FORGED] Name issues in public certificates

Richard,

Please check the updated file I posted.  My check to exclude certain
certificates was broken in the first pass but the revised version properly
excludes them.

The content is still at
https://docs.google.com/spreadsheets/d/1lJt-1tkgKcbw5woEr4-tcpqB-M-HKwjFNSdX2jla2EU/edit?usp=sharing,
but has been updated.

Thanks,
Peter

On Tue, Nov 17, 2015 at 6:07 PM, Richard Wang  wrote:
> I checked your list that the excel list number are: 6653 -- 6662,
> 29830 -- 29841, 30434 -- 30437, they are all Client certificates
> without serverAuth EKU, but listed, please check it, thanks.
>
> The attached certificate is No. 6653, please check its EKU, thanks.
>
>
> Best Regards,
>
> Richard
>
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Wednesday, November 18, 2015 12:33 AM
> To: Richard Wang 
> Cc: Rob Stradling ; Peter Gutmann
> ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: [FORGED] Name issues in public certificates
>
> On Tue, Nov 17, 2015 at 6:12 AM, Richard Wang  wrote:
>> I also found some mistakes for the list:
>> 1. I see some client certificate in the report that it say the email
>> as common name is wrong;
>
> I filtered for certificates that includes the serverAuth EKU or do not
> include any EKUs.  Can you provide an example of a clientAuth
> certificate that was incorrectly included?
>
>> 2. IP address is allowed by BR;
>
> IP addresses are only allowed in the commonName or as IPAddress type
> in the SAN extension.  If the rule is _ipv4_not_allowed_here, then
> that means that an IP address was included in a SAN as a DNS Name,
> which is disallowed. I will also fix the IP check to differentiate
> between reserved IPs (as defined in the
> BRs) and special purpose IPs (which are allowed if not reserved).  The
> BRs do not clearly state that 192.168.0.0/24, 172.16.0.0/12, and other
> special purpose IPs are disallowed.
>
>> 3. IDN is allowed, but also in the report
>
> See my note to Rob; I'm fixing that.  I misread RFC 5280 section 7.2.
>
> Thanks,
> Peter
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


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: [FORGED] Name issues in public certificates

[Rob Stradling]

Peter, yes, let's discuss that list at CABForum.

I would also like to get clarification on if/when the underscore 
character may be used in each of the name types.  Your report seems to 
flag underscores as always prohibited (I think), but I expect that some 
CAs would be surprised by that.


On 18/11/15 02:14, Peter Bowen wrote:

Based on writing the code to these checks, I think it would be good
for the CAB Forum to consider the following clarifications/changes:

1) for dNSname type GeneralNames, make sure implementers are aware
that the "preferred name synatx" in RFC1034  does not allow a trailing
period on a Domain Name (example.com. is not valid) and are aware that
leading and trailing whitespace is not allowed.

2) For commonName attributes in subject DNs, clarify that they can only contain:
- IPv4 address in dotted-decimal notation (specified as IPv4address
from section 3.2.2 of RFC 3986)
- IPv6 address in coloned-hexadecimal notation (specified as
IPv6address from section 3.2.2 of RFC 3986)
- Fully Qualified Domain Name or Wildcard Domain Name in the
"preferred name syntax" (specified by Section 3.5 of RFC1034 and as
modified by Section 2.1 of RFC1123)
- Fully Qualified Domain Name or Wildcard Domain Name in containing
u-labels (as specified in RFC 5890)

3) Forbid commonName attributes in subject DNs from containing a Fully
Qualified Domain Name or Wildcard Domain Name that contains both one
or more u-labels and one or more a-labels (as specified in RFC 5890).

4) Forbid all IP addresses that are listed in
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
or in 
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
except those with global = true.

If the Forum decides to allow an exception to RFC 5280 to permit IP
address strings in dNSName general names, then require the same format
as allowed for common names.

Thanks,
Peter

On Tue, Nov 17, 2015 at 1:17 PM, Jeremy Rowley
 wrote:

They were until Feb 2013 :)

Sure - let's discuss these issues at the CAB Forum. Based on the spreadsheet, 
I'm pretty sure lots of CAs would like to re-address the elimination of all 
SANs except iPAddress and dNSANames.

-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com]
Sent: Tuesday, November 17, 2015 2:12 PM
To: Jeremy Rowley
Cc: Richard Wang; mozilla-dev-security-pol...@lists.mozilla.org; Peter Bowen; 
Peter Gutmann
Subject: Re: [FORGED] Name issues in public certificates

On 17/11/15 18:27, Jeremy Rowley wrote:

Encoding an IP Address in a dNSName is not permitted by the BRs.  This is what Peter's 
"_ipv4_not_allowed_here" rule refers to, IIUC.
[JR] I suppose that is true under 7.1.4.2.1 but how would you get the browsers 
to work back then? Chrome and IE did not process ipAddress properly.


Jeremy, I don't recall any clause in the BRs that permits CAs to ignore 
requirements that they or their customers don't like.

They are not Baseline Suggestions! ;-)

If (whilst the BRs have been in force) there's been a perceived need to encode 
IP addresses in dNSName fields, then don't you think that the correct thing to 
do would've been to take the matter to CABForum and seek to update the BRs so 
that this practice is permitted?


Jeremy


Regards,

Richard

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.
o
rg] On Behalf Of Rob Stradling
Sent: Tuesday, November 17, 2015 9:32 PM
To: Peter Gutmann ; Peter Bowen
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: [FORGED] Name issues in public certificates

On 17/11/15 08:25, Peter Gutmann wrote:

Peter Bowen  writes:


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


That's still pretty scary, nearly 50,000 names from a who's-who of
commercial CAs.  Yet more evidence that, like the output from the
EFF SSL Observatory, we need independent assessment of browser PKI
rather than self-certification ("we define ourselves to be in full
compliance with everything we need to be compliant with, as far as we can 
tell").

Peter.


Peter (G),

I fully agree that independent assessment is useful, but independent
assessments need to be assessed too (preferably before the press
start quoting soundbites! :-) )

Peter (B),

Thanks for doing this report.  There are definitely some interesting findings.
However, I would like to discuss several classes of (what I think
are) false positives that cover a significant number of the "anomalies" you've 
found:

  - RFC5280 sections 7.2 and 7.3 do indeed talk about the need for
dNSNames, domainComponents, etc, to only contain ASCII data.
However, your report also flags Subject CNs with non-ASCII data -
AFAICT, this is permitted by both
RFC5280 and the BRs.  It is common 

Re: [FORGED] Name issues in public certificates

[Brian Smith]

Peter Bowen  wrote:

> 2) For commonName attributes in subject DNs, clarify that they can only
> contain:
>
- IPv4 address in dotted-decimal notation (specified as IPv4address
> from section 3.2.2 of RFC 3986)
> - IPv6 address in coloned-hexadecimal notation (specified as
> IPv6address from section 3.2.2 of RFC 3986)
> - Fully Qualified Domain Name or Wildcard Domain Name in the
> "preferred name syntax" (specified by Section 3.5 of RFC1034 and as
> modified by Section 2.1 of RFC1123)
> - Fully Qualified Domain Name or Wildcard Domain Name in containing
> u-labels (as specified in RFC 5890)


> 3) Forbid commonName attributes in subject DNs from containing a Fully
> Qualified Domain Name or Wildcard Domain Name that contains both one
> or more u-labels and one or more a-labels (as specified in RFC 5890).
>

I don't think these rules are necessary, because CAs are already required
to encode all this information in the SAN, and if there is a SAN with a
dNSName and/or iPAddress the browser is required to ignore the subject CNs.
That is, if the certificate a SAN with a dNSName and/or iPAddress entry,
then it doesn't really matter how the CN is encoded as long as it isn't
misleading.


> If the Forum decides to allow an exception to RFC 5280 to permit IP
> address strings in dNSName general names, then require the same format
> as allowed for common names.
>

That should not be done. As I mentioned in my other reply in this thread,
Ryan Sleevi already described a workaround that seems to work very well:
Encode the IP addresses in the SubjectAltName as iPAddress entries, and
then also encode them as (normalized) ASCII dotted/colon-separated text in
the subject CN, using more than one subject CN if there is more than one IP
address.

By the way, I believe that mozilla::pkix will reject all the invalid names
that you found, except it accepts "_" in dNSNames. If you found some names
that mozilla::pkix accepts that you think are invalid, I would love to hear
about that.

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

Re: [FORGED] Name issues in public certificates

[Brian Smith]

On Tue, Nov 17, 2015 at 4:40 PM, Richard Wang  wrote:

> So WoSign only left IP address issue that we added both IP address and DNS
> Name since some browser have warning for IP address only in SAN.
>

Put the IP addresses in the SAN as an iPAddress and then also put them in
the Subject CN, one CN per IP address. Then all browsers will accept the
certs and they will conform to the baseline requirements (IIUC).

Note that this is Ryan Sleevi's good idea.

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

Re: [FORGED] Name issues in public certificates

[Peter Bowen]

On Wed, Nov 18, 2015 at 5:43 PM, Brian Smith  wrote:
> Peter Bowen  wrote:
>>
>> 2) For commonName attributes in subject DNs, clarify that they can only
>> contain:
>>
>> - IPv4 address in dotted-decimal notation (specified as IPv4address
>> from section 3.2.2 of RFC 3986)
>> - IPv6 address in coloned-hexadecimal notation (specified as
>> IPv6address from section 3.2.2 of RFC 3986)
>> - Fully Qualified Domain Name or Wildcard Domain Name in the
>> "preferred name syntax" (specified by Section 3.5 of RFC1034 and as
>> modified by Section 2.1 of RFC1123)
>> - Fully Qualified Domain Name or Wildcard Domain Name in containing
>> u-labels (as specified in RFC 5890)
>>
>>
>> 3) Forbid commonName attributes in subject DNs from containing a Fully
>> Qualified Domain Name or Wildcard Domain Name that contains both one
>> or more u-labels and one or more a-labels (as specified in RFC 5890).
>
>
> I don't think these rules are necessary, because CAs are already required to
> encode all this information in the SAN, and if there is a SAN with a dNSName
> and/or iPAddress the browser is required to ignore the subject CNs. That is,
> if the certificate a SAN with a dNSName and/or iPAddress entry, then it
> doesn't really matter how the CN is encoded as long as it isn't misleading.

I'll leave that up to the Forum.  I would prefer that we not have
common names with arbitrary data, but if so, so be it.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy