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 ( 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
or in
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.


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 []
Sent: Tuesday, November 17, 2015 2:12 PM
To: Jeremy Rowley
Cc: Richard Wang;; 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 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?




-----Original Message-----
From: dev-security-policy
rg] On Behalf Of Rob Stradling
Sent: Tuesday, November 17, 2015 9:32 PM
To: Peter Gutmann <>; Peter Bowen
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 


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 

      - 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 practice to put the "xn--" ASCII
string in a dNSName and the UTF-8 string in the Subject CN.

      - You wanted to check that "public CAs were following the
CA/Browser Forum baseline requirements" when issuing certs.  However,
some of the certs in your report were issued before any of the
browsers / audit regimes demanded that public CAs be compliant with the BRs.
Furthermore, some of the certs in your report were issued before the
BRs even existed.

      - You wanted to check "server auth certificates issued by public CAs".
However, I see some Code Signing Certificates in your report.

I'm pretty optimistic that all of the "anomalies" issued by Comodo's
CA system (except for the 8 mentioned in our recent incident report)
will be found to fall into these categories, although I haven't done
an exhaustive analysis yet.  If there are any other "anomalies",
they're a bit lost in the noise at present!

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
dev-security-policy mailing list

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software.
dev-security-policy mailing list

Reply via email to