[cabfpub] C=GR, C=UK exceptions in BRs

[Kirk Hall]

Ryan – you raise a good point.  Is it ever right to deviate from published industry standards, even for good cause?

Has Google ever deviated from any published standards for a good reason?  RFC 5280?  Any other standards?  If yes, how did Google balance the benefits from following a published, widely established and utilized standard, versus the desire to do things another way?

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Friday, March 17, 2017 5:15 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Peter Bowen <pzb at amzn.com>; Kirk Hall <Kirk.Hall at entrustdatacard.com>
Subject: Re: [cabfpub] C=GR, C=UK exceptions in BRs



On Fri, Mar 17, 2017 at 8:09 PM, Kirk Hall via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
in general, I think a country should be able to decide that for itself.

It sounds like you're opposed to including identity information in certificates, or at least opposed to providing a standard that Browsers might be able to rely on, because this impinges on the ability of countries to set their own policies.

Is this correct? If not, could you highlight why you don't believe a country should also be able to set its own requirements as to what fields appear in a certificate (as practiced by various government PKIs, as the recent discussion with Li-Chun presents).

Do you also believe countries should be able to set their own rules on how domains are validated? If not, could you explain what the difference is?

This would be useful and insightful to understand how to put what appears to be two logically and practically inconsistent views together - that Entrust supports identity information in certificates, but opposes mandating how that information is encoded or validated. How can relying parties effectively use this information?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170318/81d4b3b0/attachment-0003.html>