[cabfpub] Misissuance of certificates

Dean Coclin Dean_Coclin at symantec.com
Thu Jan 21 14:11:50 UTC 2016


Well, aren't we fine as long as no one misissues those types of certificates? :)

 

>>Yes we are, but the way I understand the ballot, if a CA makes a typo in the name, that triggers this disclosure. So for example, the cert for “John Smith” is issued as “John Smiths” and is immediately revoked and reissued, the CA would have to go through this reporting requirement. 

 

That is, more aptly, that publicly trusted certificates should be seen as containing public data, and that systems that rely on the privacy of some of that data should not place them in the certificates

 

>>You are suggesting that HMRC change the way THEY do things. Perhaps that is possible, but I wouldn’t hold my breath ;-)

 

.

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, January 20, 2016 10:31 PM
To: Dean Coclin <Dean_Coclin at symantec.com>
Cc: Gervase Markham <gerv at mozilla.org>; Sigbjørn Vik <sigbjorn at opera.com>; public at cabforum.org
Subject: Re: [cabfpub] Misissuance of certificates

 

 

On Wed, Jan 20, 2016 at 7:24 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

The issue was that some certs have information as part of the CN which probably shouldn't be public -- in the HMRC cases, it's a tax-related ID number specific to a given company, which probably ought to be private between that company and the tax offices. But they need certs including that number to exchange information with the tax offices. (Arguably that's a poorly designed system but that's something to take up with HMRC -- the UK tax office)

 

Well, aren't we fine as long as no one misissues those types of certificates? :)

 

That is, this only becomes an issue if something is done improperly, which hopefully should never happen, and for which it gives adequate time (since as long as the CA doesn't misissue, they don't have to disclose) for the CA to reach out and notify their customers about this change. That is, more aptly, that publicly trusted certificates should be seen as containing public data, and that systems that rely on the privacy of some of that data should not place them in the certificates (or, if necessary, indirect them through a variety of means - whether an extension which the CA understands, and is thus permitted to include-if-vetted, out of band delivery mechanisms, etc)

 

At one time, there was a suggestion that it would be okay to redact the CN back to the domain itself rather than publishing the full CN in cases of misissuance. That would certainly solve the problem in this case.  If this was the resolution that you were thinking about Gerv and if it's still in play, then perhaps you are right and it is solved.

 

The problem with CN-redaction is that no longer discloses the misissued certificate in a way that can be verified or vetted by the public, which, given that it only arises during misissuance, may be at a time when the public is least trusting of the CA. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160121/376363f1/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160121/376363f1/attachment-0001.p7s>


More information about the Public mailing list