[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

[Tim Hollebeek]

Certainly you’re aware of the Apple proposal to put revocation contact information into certificates that was discussed this Spring in Virginia? Various validation working group calls have at various times discussed putting richer validation information into certificates beyond Wayne’s proposal.  Stuffing random stuff into certificates is sort of a cottage industry at IETF, where luckily those attempts usually fail.  There’s also various proposals for adding information about potential locations to retrieve post-quantum public keys, as discussed in London.  There are a couple of other reasonable proposals I can’t talk about publicly.

 

Other proposals to add this, that, or the other thing to certificates surface regularly on various fora I follow.  I can’t provide an exhaustive set of links, because I simply do not have the time.  But that doesn’t mean they don’t exist.  In many of these cases, a Certificate Metadata log would be a better solution than stuffing additional information into certificates.  Internally here, the pros and cons for various use cases are debated regularly.

 

Of course, the biggest roadblock is that currently such logs don’t exist.  But that’s a fixable problem, for those companies with CT implementations.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, August 9, 2018 10:16 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: James Burton <burton at typewritten.net>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

 

 

On Thu, Aug 9, 2018 at 1:01 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

James,

 

This is actually a good suggestion and I’ve suggested it before, including this several times this spring.  I am very concerned about the fact that just within the last year, there have been a number of proposals that would significantly expand certificate size by including information that does not actually need to be in the certificate.

 

Can you provide links for what you believe at proposals that would "significantly expand certificate size"?

 

I can find one such reference in https://cabforum.org/pipermail/validation/2018-August/001001.html , which hasn't been expanded on.

  

I’ve actually suggested several times that Certificate Metadata Transparency should be a thing.  CAs could securely assert all sorts of rich metadata information about validation or issuance of certificates, including validation methods, problem report addresses, CAA lookup information that was retrieved, and so on.

 

Yes, and several times, it's been pointed out that sticking the suffix "Transparency" on something does not magically make it reliable, much in the same way that sticking "Blockchain" in your marketing can easily net you ample funding, but no real credibility or technology. These suggestions have, to date, ignored the significant (6+ years, now) set of design discussions and considerations gone into making this information usable and deployable. There are plenty of unsound technologies with cute names that capture whatever word was en vogue, like 'mesh', but aren't technically sound nor address the problem at hand.

 

To be clear, I'm all in favor of CAs improving the transparency of their operations - as has been clearly demonstrated by the need to improve the current state of audits and disclosures - but the notion of "securely assert" has a whole host of devils in the details, and we should not ignore good and necessary work on the promise that we're only "an email away" from a solution.

 

The unfortunate thing is such logs don’t exist yet.  However DigiCert might set them up in the future, and start allowing other CAs to log metadata information about their issued certificates to our logs.  It’s something we’re seriously considering doing.

 

If DigiCert has meaningful, technically sound proposals to put forward, we'd be happy to review. That said, it should not be unreasonable to expect that it will be far more difficult to do than to say it will be done.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180809/54a88ba9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180809/54a88ba9/attachment-0001.p7s>