[cabfpub] Putting OIDs for the manufacturer of your kitchen sink into certificates

Tim Hollebeek tim.hollebeek at digicert.com
Tue May 1 14:45:35 MST 2018

> To make sure I understand: Are you proposing an explicit prohibition against 
> including any other extension or metadata within a Certificate

Wow, no, certainly nothing so extreme.  There is certainly some metadata that 
is necessary and appropriate within the certificate itself.  Certainly 
anything that a browser uses or wants to use for trust decisions should be in 
the certificate itself.  I just think that not ALL such metadata belongs in 
certificates ...

> If not, I'm not sure what you're proposing here - CAs that want to include 
> information will be able to, just as they are today.

Sure, DigiCert can put kitchen sinks into certificates today, and we totally 
will, when it's appropriate.  I just think there is some value in 
standardizing across the industry what information is available where, instead 
of having all CAs make independent decisions.

> While I agree that there are all sorts of terrible ideas for things to stuff 
> into certificates (if only because those proposing may not be aware of the 
> technical constraints or the alternatives that exist), there's also plenty 
> of good ideas.

Agreed.  Which is why I'm hoping this will be a useful discussion that will 
provide some good guidance going forward on what is and is not a good idea.

> Regarding your dislike of the poison extension, how does that square with 
> RFC 6962-bis? Are you saying that you don't believe 6962-bis already 
> accommodates the system you're describing, or that you don't want to wait 
> for 6962-bis to be deployed to be able to take advantage of this? If the 
> latter, do you have specific, concrete examples that might demonstrate why 
> it's more valuable sooner than later?

I think RFC 6962-bis is a perfectly reasonable solution to the poison 
extension problem, and am in no particular hurry to solve that problem, since 
all it does is annoy my preferences about architectural cleanliness, and there 
are plenty of other things that annoy me along those lines that can distract 
me from this particular annoyance.

I just don't want people creating any ADDITIONAL divergences between CT logged 
certificates and real certificates.

-------------- 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/public/attachments/20180501/0e3ce700/attachment.p7s>

More information about the Public mailing list