Re: DigiCert BR violation

[Peter Bowen via dev-security-policy]

On Mon, Mar 13, 2017 at 6:08 PM, Nick Lamb via dev-security-policy
 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: DigiCert BR violation

[Nick Lamb via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: DigiCert BR violation

[Jeremy Rowley via dev-security-policy]

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=digicert.com@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, March 13, 2017 3:32 PM
To: mozilla-dev-security-pol...@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?
___
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: DigiCert BR violation

[Jeremy Rowley via dev-security-policy]

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 

Re: DigiCert BR violation

[Ryan Sleevi via dev-security-policy]

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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy