DigiCert BR violation

[Ryan Sleevi]

It appears that DigiCert has violated the Baseline Requirements, as recently notified to the CA/Browser Forum.

The certificate at https://crt.sh/?id=98120546 does not comply with RFC 5280.

RFC 5280 defines the upper-bound of the commonName field as 64 characters, specifically

ub-common-name INTEGER ::= 64
-- Naming attributes of type X520CommonName:
-- X520CommonName ::= DirectoryName (SIZE (1..ub-common-name))
--
-- Expanded to avoid parameterized type:
X520CommonName ::= CHOICE {
teletexString TeletexString (SIZE (1..ub-common-name)),
printableString PrintableString (SIZE (1..ub-common-name)),
universalString UniversalString (SIZE (1..ub-common-name)),
utf8String UTF8String (SIZE (1..ub-common-name)),
bmpString BMPString (SIZE (1..ub-common-name)) }

The commonName encoded in this certificate is 67 characters

[Kurt Roeckx]

Digicert also has many certificates were the organizationName is too
long. An example: https://crt.sh/?id=100279600. See
https://crt.sh/?x509lint=363 for a list of recent ones.

RFC5280 has:
-- Naming attributes of type X520OrganizationName

id-at-organizationName AttributeType ::= { id-at 10 }

-- Naming attributes of type X520OrganizationName:
-- X520OrganizationName ::=
-- DirectoryName (SIZE (1..ub-organization-name))

--
-- Expanded to avoid parameterized type:

X520OrganizationName ::= CHOICE {
teletexString TeletexString
(SIZE (1..ub-organization-name)),
printableString PrintableString
(SIZE (1..ub-organization-name)),
universalString UniversalString
(SIZE (1..ub-organization-name)),
utf8String UTF8String
(SIZE (1..ub-organization-name)),
bmpString BMPString
(SIZE (1..ub-organization-name)) }

ub-organization-name INTEGER ::= 64

It would be nice that they fixed this. But this is lower on my priority
list then some of the others at https://crt.sh/?cablint=issues.


Kurt

[Jeremy Rowley]

Thanks. This certificate was issued by an employee of DigiCert as a test on
our systems to see if we'd resolved an issue with a path permitting CN
fields greater than 64 characters. Obviously, the issue wasn't resolved and
the JIRA is still open. We're deploying a patch shortly to fix path and
limit the string to 64 characters. All required validation was completed
successfully prior to issuing the certificate. Although we have a policy
against using live certificates for testing, the policy was not followed in
this case. Prior to issuing the certificate, we actually checked to see if
any other certificates existed with a CN length longer than 64 chars
(basically to see if this path had ever been used by a customer). There are
no other certificates with that long of common name, meaning this issue
should be resolved with the patch.

However, I think this discussion raises some very interesting points about
real world scenarios and RFC 5280 that should be addressed. DigiCert
actually has three items that routinely show up on CABLint:
1) Use of teletext in strings (although this only occurs in
re-issues/duplicates of previously issued certificates)
2) Too long of fields, primarily the O and OU fields
3) Use of underscore characters in certs

We've had an open item to fix these issues for a while, but haven't
prioritized them because:
a) From a technical standpoint, the WebPKI supports them,
b) The inclusion of longer names reflects the real world where company
names are often longer than 64 char, especially in Europe and Asia
(translating international names to puny-code rarely results in a nice short
name),
c) We haven't felt that there are sufficiently significant risks
associated with the issues to spend resources addressing them considering a
and b compared to higher priorities (like our current project of requiring
only 169 validation methods), and
d) Lots of CAs have the same or similar issues under RFC 5280 according
to CABLint, and those issues don't seem to be garnering a lot of attention
(perhaps because of higher risk issues taking priority).

DigiCert and its employees observe two guiding principles in our daily
activities: 1) Improve security and 2) Support the customer. Occasionally,
these principles are not compatible. For example, most of our customers
hate CT. However, we support the CT project because CT and publicly logging
certificates substantially improves the transparency (and thus security) of
the web. Similarly, we haven't removed underscore characters or limited the
O field to 64 characters because the risks seem insignificant compared to
the large number of companies that would not be able to obtain a
certificate. In fact, I think security is improved by providing these
certificates because these customers/domains would remain unsecured without
certificates or be forced to truncate/omit important information. I believe
most CAs have reached the same conclusion after considering the large number
of issues reported through CABLint.

The discussion also raises an interesting question of when issues become
significant enough they need to be addressed on the Mozilla list or require
revocation. For example, one of our cross-signed partners issued a large
number of certificates that lacked the proper OID. Should each of these
certs warrant a discussion and separate revocation decision? The browsers
don't do anything with this information so I'm unsure whether them revoking
all the certs (which the cross-signed partner did) and replacing them with
certs having an appropriate policy OID made a huge difference in the state
of security. Should we start a thread on the Mozilla list about each cert
with issues detected in CABLint? Even if we assume half are false positives,
that's about 2000 new discussion items for this group. If so, can we
establish a priority ranking by the browsers for these discussions?

Jeremy

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

[Ryan Sleevi]

(Wearing an individual hat)

On Thu, Mar 9, 2017 at 4:18 PM, Jeremy Rowley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Although we have a policy
> against using live certificates for testing, the policy was not followed in
> this case.

Can you share why? Can you share what steps you'll be taking to make sure
policies are followed in the future? I think we've seen some pretty stark
examples about what can happen when a CA doesn't follow its policies for
test certificates - from CNNIC to Symantec.

> However, I think this discussion raises some very interesting points about
> real world scenarios and RFC 5280 that should be addressed. DigiCert
> actually has three items that routinely show up on CABLint:
> 1) Use of teletext in strings (although this only occurs in
> re-issues/duplicates of previously issued certificates)
>

Is this in the issuer field? Or in the subject information? I can
understand if your issuer cert has this issue, but I don't think there's
any good reason for this for the subject information.

> 2) Too long of fields, primarily the O and OU fields
> 3) Use of underscore characters in certs


> We've had an open item to fix these issues for a while, but haven't
> prioritized them because:
> a) From a technical standpoint, the WebPKI supports them,
> b) The inclusion of longer names reflects the real world where company
> names are often longer than 64 char, especially in Europe and Asia
> (translating international names to puny-code rarely results in a nice
> short
> name),
> c) We haven't felt that there are sufficiently significant risks
> associated with the issues to spend resources addressing them considering a
> and b compared to higher priorities (like our current project of requiring
> only 169 validation methods), and
> d) Lots of CAs have the same or similar issues under RFC 5280
> according
> to CABLint, and those issues don't seem to be garnering a lot of attention
> (perhaps because of higher risk issues taking priority).
>

I gotta admit, this sounds pretty disheartening.

"We know we have issues, we've known about them for a while, but we've kept
doing it, because we don't think it's a big deal, and everyone else is
doing it".

The BRs, in part, exist to avoid that judgement call, because we see time
and time again where CAs are making that judgement call and it's not ending
well. If you don't think it belongs, then why not propose BR changes? If
you don't think it's important, then why not propose root policy changes?

I appreciate the effort towards only 169 validation methods, but how are
we, the relying parties, supposed to know that DigiCert won't, say,
deprioritize following the BRs on that because y'all decide it's not a big
security issue, and instead want to focus on a new product offering, since
(besides whatever revenue benefit it might have), it gets more sites on
HTTPS?

As for other CAs, shouldn't you be making sure your house is in order
first? :) But also, if there are other issues, shouldn't you be pushing for
greater disclosure and transparency? We constantly see this correlation
between smoke and fire - and if you're seeing smoke, don't you think it
should be raised?

I appreciate the principled stance you're mention, but I'm sure you can
realize the systemic and endemic harm that comes from "Trust us to evaluate
whether compliance is right or not" - we know that's absolutely a failed
mindset from the past decade of failures. Why isn't the principle "Be above
reproach" - which includes improving security as a natural consequence?

> In fact, I think security is improved by providing these
> certificates because these customers/domains would remain unsecured without
> certificates or be forced to truncate/omit important information. I believe
> most CAs have reached the same conclusion after considering the large
> number
> of issues reported through CABLint.
>

"We should be able to misissue certs, because at least people are on HTTPS"
- this is a terrible argument, and I have a tremendous amount of respect
for you, but I'm shocked to hear you make it, given your knowledge of the
industry. Misissuance of any form is a terrible practice, regardless of the
reasons, precisely because it starts us into the subjective realm.

> The discussion also raises an interesting question of when issues become
> significant enough they need to be addressed on the Mozilla list or require
> revocation. For example, one of our cross-signed partners issued a large
> number of certificates that lacked the proper OID. Should each of these
> certs warrant a discussion and separate revocation decision?

Discuss the problem - not the certificates.

Discuss what you're doing to address the problem. What caused the issue.
How many certificates did it affect? What steps are you taking? When will
those be complete?

> The browsers
> don't do anything with this information so I'm unsure whether them revoking
> all the certs (which the cross-signed partner did) and replacing them with
> certs having an appropriate policy OID made a huge difference in the state
> of security. Should we start a thread on the Mozilla list about each cert
> with issues detected in CABLint?

Yes! If they're violations of the Baseline Requirements, yes! If you're not
sure, yes! If you can't point to a specific reason why it is a false
positive - by showing, for example, a misinterpreted or misapplied rule -
absolutely!

> Even if we assume half are false positives,
> that's about 2000 new discussion items for this group. If so, can we
> establish a priority ranking by the browsers for these discussions?
>

Everything?

Look, you're representing an organization trusted with the keys for the
Internet. Billions - plural - of products rely on you to exercise a duty of
care with that trust. Today, that duty of care is measured by how well you
follow the Baseline Requirements, and how seriously you take that duty of
care. It's great that you feel you're doing a bangup job and these are
minor issues, but don't sweep them under the rug. Be transparent. Be
honest. Be open. And be willing to acknowledge that things can and do need
to change.

Are the BRs perfect? No. Are IETF docs perfect? Of course not. But they're
the bare minimum, and failure to abide by those rules, especially on a
systemic and knowing basis, vastly undermines trust, because it's unclear
what other corners you might be willing to cut without telling anyone. And
that's a suspicion that you shouldn't stoke by brushing the concerns off as
glibly as this seems to.

[Kurt Roeckx]

On Thu, Mar 09, 2017 at 06:29:57PM -0500, Ryan Sleevi via dev-security-policy wrote:
> > However, I think this discussion raises some very interesting points about
> > real world scenarios and RFC 5280 that should be addressed. DigiCert
> > actually has three items that routinely show up on CABLint:
> > 1) Use of teletext in strings (although this only occurs in
> > re-issues/duplicates of previously issued certificates)
> >
>
> Is this in the issuer field? Or in the subject information? I can
> understand if your issuer cert has this issue, but I don't think there's
> any good reason for this for the subject information.

RFC5280 has this:
4.1.2.6. Subject
[...]
When encoding attribute values of type DirectoryString, conforming
CAs MUST use PrintableString or UTF8String encoding, with the
following exceptions:
[...]
(c) TeletexString, BMPString, and UniversalString are included
for backward compatibility, and SHOULD NOT be used for
certificates for new subjects. However, these types MAY be
used in certificates where the name was previously
established, including cases in which a new certificate is
being issued to an existing subject or a certificate is being
issued to a new subject where the attributes being encoded
have been previously established in certificates issued to
other subjects. Certificate users SHOULD be prepared to
receive certificates with these types.

So you could at least argue that TeletexString is allowed in some
cases.

But I have never seen a certificate with a properly encoded
TeletexString, except when it only uses characters that are
close to what PintableString allows. Almost all seem to be putting
latin1 charactes in there while G1 is not mapped by default. And even
if G1 defaulted to 103, which I've seen some people claim, 103
isn't even close to latin1, and none of the allowed registration
numbers matches latin1 or are even close. Also note that G0
does not actually map to ASCII by default, that would be
registration 6, while the default for G0 is 102.

As far as I know none of the software I use actually supports decoding
TeletexString. There really isn't any compatibility reason to use
TeletexString. There are only reasons not to use it. And you
should have stopped using it more than 10 years ago.

I would have less of a problem with BMPString or UniversalString,
but TeletexString really just just go.


Kurt

[Jeremy Rowley]

I don't disagree that teletext shouldn't be used, and we no longer include
it in new certificate requests or renewals. However, we do include teletext
in certificates that originally had teletext strings but are being re-keyed.
Teletext inclusion wasn't intentional and should shortly be fixed.

[Ryan Sleevi]

On Monday, March 13, 2017 at 5:12:39 PM UTC-4, Jeremy Rowley wrote:
> I don't disagree that teletext shouldn't be used, and we no longer include
> it in new certificate requests or renewals. However, we do include teletext
> in certificates that originally had teletext strings but are being re-keyed.
> Teletext inclusion wasn't intentional and should shortly be fixed.

Are you saying that there are one or more clients that require DigiCert to support Teletext strings?

Do you have an ETA on the other issues?

[Jeremy Rowley]

Although we have a policy
against using live certificates for testing, the policy was not followed in
this case.



Can you share why? Can you share what steps you'll be taking to make sure policies are followed in the future? I think we've seen some pretty stark examples about what can happen when a CA doesn't follow its policies for test certificates - from CNNIC to Symantec.

[JR] In this particular case, the cause was training/policy error in this case and mostly my fault (as one of the policy drafters). We have technical processes in place to prevent the issuance of certificates with test data. We have also repeatedly communicated that test certificates cannot be issued. However, we do not technically prevent engineers from applying for certificates on the domains they own. As such, the term “test certificate” wasn’t well-defined (similar to the current BR test certificate definition). We’ve since clarified that the policy not only prohibits certs with bad data but also encourages use of private CAs for testing rather than developers registering their own domain and getting a real cert through the ordering process.

However, I think this discussion raises some very interesting points about
real world scenarios and RFC 5280 that should be addressed. DigiCert
actually has three items that routinely show up on CABLint:
1) Use of teletext in strings (although this only occurs in
re-issues/duplicates of previously issued certificates)



Is this in the issuer field? Or in the subject information? I can understand if your issuer cert has this issue, but I don't think there's any good reason for this for the subject information.

[JR] Subject field. However, this was mostly a mistake as it was fixed for all new certificates but permitted for entities replacing an existing certificate with teletext string. Should be remediated soon.

2) Too long of fields, primarily the O and OU fields
3) Use of underscore characters in certs

-cut-

I gotta admit, this sounds pretty disheartening.



"We know we have issues, we've known about them for a while, but we've kept doing it, because we don't think it's a big deal, and everyone else is doing it".



The BRs, in part, exist to avoid that judgement call, because we see time and time again where CAs are making that judgement call and it's not ending well. If you don't think it belongs, then why not propose BR changes? If you don't think it's important, then why not propose root policy changes?

[JR] If you recall, I did try to change the policy. I was told to change the RFC if I didn’t like the requirement. I find trying to change the RFC nearly impossible as PKIX is dead and there are too many other issues people would also like to change.

I appreciate the effort towards only 169 validation methods, but how are we, the relying parties, supposed to know that DigiCert won't, say, deprioritize following the BRs on that because y'all decide it's not a big security issue, and instead want to focus on a new product offering, since (besides whatever revenue benefit it might have), it gets more sites on HTTPS?



As for other CAs, shouldn't you be making sure your house is in order first? :) But also, if there are other issues, shouldn't you be pushing for greater disclosure and transparency? We constantly see this correlation between smoke and fire - and if you're seeing smoke, don't you think it should be raised?

[JR] Fair point, and I think the issues should be raised (including ours – which is why I raised the other issues in response to this post). I didn’t really think of the listed reasons as excuses, more an explanation as to what our current cablint issues are and why we haven’t resolved all of them yet. We do have most of them on the roadmap, and this discussion has helped prioritize some of them higher 😊

The discussion also raises an interesting question of when issues become
significant enough they need to be addressed on the Mozilla list or require
revocation. For example, one of our cross-signed partners issued a large
number of certificates that lacked the proper OID. Should each of these
certs warrant a discussion and separate revocation decision?



Discuss the problem - not the certificates.



Discuss what you're doing to address the problem. What caused the issue. How many certificates did it affect? What steps are you taking? When will those be complete?

[JR] The issue is already remedied and was logged as a bug with Mozilla. However, the number of certificates that required revocation and replacement seemed like a waste considering the certificates omitted an OID. Looking back, perhaps we can discuss whether some of these “mis-issues” really warrant a revoke and replace mechanism rather than simply disclosure to Mozilla and a discussion on what to do. Seems like a waste to throw all of those certs on a CRL when they function properly with browser software. Perhaps a better process than “disclose and replace” would be “disclose, discuss, and replace if necessary”. That way issues such like missing O field wouldn’t be so cost heavy on the revocation side.

[Jeremy Rowley]

No - there are no clients that need Teletext that I'm aware of.

ETA on the other issues are the CN field is already fixed to limit the size
to 64 characters. For the others, we wanted to talk to the primary customer
to let them first know the fix is going live. Should be deployed later this
week, but I want to talk to them before committing to a specific date (since
all their company names are super long).

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy

Sent: Monday, March 13, 2017 3:32 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: DigiCert BR violation

On Monday, March 13, 2017 at 5:12:39 PM UTC-4, Jeremy Rowley wrote:

> I don't disagree that teletext shouldn't be used, and we no longer
> include it in new certificate requests or renewals. However, we do
> include teletext in certificates that originally had teletext strings but
are being re-keyed.
> Teletext inclusion wasn't intentional and should shortly be fixed.

Are you saying that there are one or more clients that require DigiCert to
support Teletext strings?

Do you have an ETA on the other issues?

[Nick Lamb]

On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote:
> Are you saying that there are one or more clients that require DigiCert to support Teletext strings?

Can we stop saying Teletext? The X500 series standards are talking about Teletex. One letter shorter.

Teletext was invented by the BBC, to deliver pages of text and block graphics in the blanking interval on analogue television transmissions. It brought joy to millions of people (especially nerds) around the world for several decades prior to analogue television going off the air.

Teletex is an ITU standard, intended to supersede Fax but largely forgotten because it turns out Internet email is what people actually wanted. Its text encoding infested the X.500 series standards and thereby made dozens of people miserable.

[Peter Bowen]

On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On Monday, 13 March 2017 21:31:46 UTC, Ryan Sleevi wrote:

>> Are you saying that there are one or more clients that require DigiCert to support Teletext strings?
>

> Can we stop saying Teletext? The X500 series standards are talking about Teletex. One letter shorter.
>
> Teletext was invented by the BBC, to deliver pages of text and block graphics in the blanking interval on analogue television transmissions. It brought joy to millions of people (especially nerds) around the world for several decades prior to analogue television going off the air.
>
> Teletex is an ITU standard, intended to supersede Fax but largely forgotten because it turns out Internet email is what people actually wanted. Its text encoding infested the X.500 series standards and thereby made dozens of people miserable.

I thought teletex was there to make people who use reverse solidus
('\'), circumflex ('^'), grave accent ('`'), curly brackets ('{' and
'}') and tilde ('~') sad.

[Kurt Roeckx]

The 102 registration also has a ¤ instead of a $ if I remember
correctly. But that's just the default and with just a few bytes you can
switch it to ASCII (registration 6).


Kurt

[Gervase Markham]

On 13/03/17 21:31, Jeremy Rowley wrote:
> [JR] If you recall, I did try to change the policy. I was told to
> change the RFC if I didn’t like the requirement. I find trying to
> change the RFC nearly impossible as PKIX is dead and there are too
> many other issues people would also like to change.

If RFCs are unchangeably wrong, we should override them in the BRs.
[citation needed] for the discussion where you were told to change the
RFC; I'd like to read how that conversation went.

Gerv