<div dir="ltr">Again, I highlight, we have not determined that 9.16.3 is appropriate for this case.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 9, 2017 at 6:57 PM, Jeremy Rowley via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes. That's why I said this is the correct approach. They won't received a qualified audit<br>
<span class="im HOEnZb"><br>
-----Original Message-----<br>
From: Kirk Hall [mailto:<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@<wbr>entrustdatacard.com</a>]<br>
Sent: Thursday, March 9, 2017 3:48 PM<br>
To: Jeremy Rowley <<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@digicert.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
Cc: Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>><br>
</span><div class="HOEnZb"><div class="h5">Subject: RE: [cabfpub] Naming rules<br>
<br>
Jeremy - not sure I understand your message, but if you saw Jeff Ward's email, it appears a CA that properly uses BR 9.16.3 will receive an unqualified WebTrust report (with disclosures) and not a qualified report.<br>
<br>
-----Original Message-----<br>
From: Jeremy Rowley [mailto:<a href="mailto:jeremy.rowley@digicert.com">jeremy.rowley@<wbr>digicert.com</a>]<br>
Sent: Thursday, March 9, 2017 2:33 PM<br>
To: CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>>; Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a><wbr>><br>
Cc: Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>><br>
Subject: RE: [cabfpub] Naming rules<br>
<br>
Right - the Microsoft root program requires a WebTrust seal for inclusion according to the agreement. Therefore, the best path forward is one that does not require a qualified audit as it precludes a WebTrust seal. This is a good way to satisfy both concerns, permitting a WebTrust seal while still giving notice that there is a conflict between national law and the BRs.<br>
<br>
-----Original Message-----<br>
From: Public [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@<wbr>cabforum.org</a>] On Behalf Of Peter Bowen via Public<br>
Sent: Sunday, March 5, 2017 7:38 PM<br>
To: Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a><wbr>><br>
Cc: Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
Subject: Re: [cabfpub] Naming rules<br>
<br>
Kirk,<br>
<br>
I’m afraid you misunderstood a portion of my suggestion. There is nothing here about BR 9.16.3. This is a suggestion of taking a coordinated intentional audit qualification, which _will_ result in not receiving a WebTrust seal. Depending on the definition of “successful”, it very well may not be a successful audit.<br>
<br>
If the objective is to allow the Government Certification Authority operated by Chunghwa Telecom to receive a WebTrust seal and to allow them to use their existing names in their DIT for Subject Names, then the criteria for WebTrust must be updated in such a way to allow the name forms as-is. This inherently does mean changing the BRs, as I understand it.<br>
<br>
Thanks,<br>
Peter<br>
<br>
> On Mar 5, 2017, at 2:18 PM, Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a><wbr>> wrote:<br>
><br>
> +1. Seems like a good resolution to me - full disclosure to users and browsers, deference to local law where applicable as provided in BR 9.16.3 (local users are probably already used to any local customs on naming rules), and avoids the need for the Forum to try to understand and approve/disapprove local naming rules one by one. Allows auditors to complete successful audits with disclosure, and the trust list maintainers receive notice and can make their own decisions.<br>
><br>
> -----Original Message-----<br>
> From: Peter Bowen [mailto:<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>]<br>
> Sent: Sunday, March 5, 2017 12:06 PM<br>
> To: CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
> Cc: Kirk Hall <<a href="mailto:Kirk.Hall@entrustdatacard.com">Kirk.Hall@entrustdatacard.com</a><wbr>><br>
> Subject: Re: [cabfpub] Naming rules<br>
><br>
> To wrap us discussion of this issue and provide a way for Chunghwa Telecom to proceed, I believe Chunghwa Telecom (and any other CA in a similar situation) should do the following:<br>
><br>
> 1) Ensure that their CPS otherwise meets the BRs<br>
> 2) Add a clear callout in the CPS that the Names in certificates (usually in section 3.1) don’t comply with the BRs<br>
> 3) Ensure that the CPS clearly defines the rules for names (so the auditor can confirm that the issued certificates meet the rules)<br>
> 4) Discuss this with each organization that requires following the BRs as part of accepting roots to their trust list<br>
> 5) Add something like “during the period XX to YY, Chunghwa Telecom […] based on the WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security v2.0 except Subject Information in certificates issued did meet the minimum requirements for Certificate Content and profile.” to their management assertion. This could be followed up with a sentence similar to “Instead, Subject Information conformed to ZZZZ” (whatever regulation is appropriate)<br>
> 6) Then the auditor will include a very similar sentence in their opinion letter.<br>
><br>
> This will not require any changes to the BRs or any further action by the Forum. Neither the Forum nor the WebTrust task force mandates following the BRs. It is to each trust list maintainer as to whether they want include a CA who uses alternative naming rules.<br>
><br>
> If others agree, I don’t think the Forum or the validation WG needs to consider this issue further.<br>
><br>
> Thanks,<br>
> Peter<br>
><br>
>> On Mar 4, 2017, at 5:55 PM, Kirk Hall via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</a>> wrote:<br>
>><br>
>> Great explanation, Peter - thanks.<br>
>><br>
>><br>
>><br>
>> Gerv - maybe the BR rules came from X520? file:///C:/Users/khall/<wbr>Downloads/T-REC-X.520-201610-<wbr>I!!PDF-E.pdf<br>
>><br>
>><br>
>><br>
>> We may already have a solution that does not require any further action by the CABF. BR 9.16.3 shown below allows a CA to modify any BR requirement that conflicts with local law by (1) giving a statement and explanation in Sec. 9.16.3 of its CPS, and (2) sending a message to the CABF questions@ list with the same information.<br>
>><br>
>><br>
>><br>
>> It seems that section would apply where a national government requires a CA to use Subject Names from a Directory Information Tree operated by the national government, and that Tree conflicts with the BR naming rules. Does anyone disagree?<br>
>><br>
>><br>
>><br>
>> Li-Chun -- can you solve your problem simply by following the rules in BR 9.16.3?<br>
>><br>
>><br>
>><br>
>> 9.16.3. Severability<br>
>><br>
>><br>
>><br>
>> In the event of a conflict between these Requirements and a law, regulation or government order (hereinafter 'Law') of any jurisdiction in which a CA operates or issues certificates, a CA MAY modify any conflicting requirement to the minimum extent necessary to make the requirement valid and legal in the jurisdiction. This applies only to operations or certificate issuances that are subject to that Law. In such event, the CA SHALL immediately (and prior to issuing a certificate under the modified requirement) include in Section 9.16.3 of the CA’s CPS a detailed reference to the Law requiring a modification of these Requirements under this section, and the specific modification to these Requirements implemented by the CA.<br>
>><br>
>><br>
>><br>
>> The CA MUST also (prior to issuing a certificate under the modified requirement) notify the CA/Browser Forum of the relevant information newly added to its CPS by sending a message to <a href="mailto:questions@cabforum.org">questions@cabforum.org</a> and receiving confirmation that it has been posted to the Public Mailing List and is indexed in the Public Mail Archives available at <a href="https://cabforum.org/pipermail/public/" rel="noreferrer" target="_blank">https://cabforum.org/<wbr>pipermail/public/</a> (or such other email addresses and links as the Forum may designate), so that the CA/Browser Forum may consider possible revisions to these Requirements accordingly.<br>
>><br>
>><br>
>><br>
>> -----Original Message-----<br>
>> From: Public [mailto:<a href="mailto:public-bounces@cabforum.org">public-bounces@<wbr>cabforum.org</a>] On Behalf Of Peter Bowen via Public<br>
>> Sent: Thursday, March 2, 2017 7:29 PM<br>
>> To: CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org">public@cabforum.org</a>><br>
>> Cc: Peter Bowen <<a href="mailto:pzb@amzn.com">pzb@amzn.com</a>><br>
>> Subject: [cabfpub] Naming rules<br>
>><br>
>><br>
>><br>
>> We have had a number of discussions over the last few months about the content of Subject Names in Certificates. I promised on a recent call to try to summarize one of the issues, including the issue that Li-Chun has raised.<br>
>><br>
>><br>
>><br>
>> The Baseline Requirements specify how Names are to be constructed. There are rules about which attributes must appear in names and what the content of the attributes must be.<br>
>><br>
>><br>
>><br>
>> There are other existing PKIs with different naming rules. Another PKI could forbid an attribute required by the BRs. Alternatively another PKI could require that the full Name be taken verbatim from some other source, such as an existing Directory Information Tree; these Names many not include attributes required by the BRs.<br>
>><br>
>><br>
>><br>
>> I believe the government on Taiwan falls into the latter case. They have a PKI which has the policy that names must be taken from an existing Directory Information Tree operated by the government. Many of the Names in the existing DIT don’t include attributes that are required by the BRs. Therefore the question is whether we should make an exception to allow this existing PKI to be declared BR-compliant by adding some language like “ If a Government CA is required by its Certificate Policy to use Subject Names from a Directory Information Tree operated by a Government Entity, then section 7.1.4.2.2 shall not apply.”<br>
>><br>
>><br>
>><br>
>> Li-Chun: Did I get this right?<br>
>><br>
>><br>
>><br>
>> Others: Does this make the issue clearer?<br>
>><br>
>><br>
>><br>
>> Thanks,<br>
>><br>
>> Peter<br>
>><br>
>> ______________________________<wbr>_________________<br>
>><br>
>> Public mailing list<br>
>><br>
>> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
>><br>
>> <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Public mailing list<br>
>> <a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
>> <a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
</div></div><br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br></div>