[cabfpub] Naming rules

Thu Mar 9 16:58:05 MST 2017

Again, I highlight, we have not determined that 9.16.3 is appropriate for
this case.

On Thu, Mar 9, 2017 at 6:57 PM, Jeremy Rowley via Public <
public at cabforum.org> wrote:

> Yes. That's why I said this is the correct approach. They won't received a
> qualified audit
>
> -----Original Message-----
> From: Kirk Hall [mailto:Kirk.Hall at entrustdatacard.com]
> Sent: Thursday, March 9, 2017 3:48 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> Cc: Peter Bowen <pzb at amzn.com>
> Subject: RE: [cabfpub] Naming rules
>
> 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.
>
> -----Original Message-----
> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> Sent: Thursday, March 9, 2017 2:33 PM
> To: CA/Browser Forum Public Discussion List <public at cabforum.org>; Kirk
> Hall <Kirk.Hall at entrustdatacard.com>
> Cc: Peter Bowen <pzb at amzn.com>
> Subject: RE: [cabfpub] Naming rules
>
> 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.
>
> -----Original Message-----
> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Peter
> Bowen via Public
> Sent: Sunday, March 5, 2017 7:38 PM
> To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
> Cc: Peter Bowen <pzb at amzn.com>; CA/Browser Forum Public Discussion List <
> public at cabforum.org>
> Subject: Re: [cabfpub] Naming rules
>
> Kirk,
>
> 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.
>
> 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.
>
> Thanks,
> Peter
>
> > On Mar 5, 2017, at 2:18 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com>
> wrote:
> >
> > +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.
> >
> > -----Original Message-----
> > From: Peter Bowen [mailto:pzb at amzn.com]
> > Sent: Sunday, March 5, 2017 12:06 PM
> > To: CA/Browser Forum Public Discussion List <public at cabforum.org>
> > Cc: Kirk Hall <Kirk.Hall at entrustdatacard.com>
> > Subject: Re: [cabfpub] Naming rules
> >
> > 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:
> >
> > 1)      Ensure that their CPS otherwise meets the BRs
> > 2)      Add a clear callout in the CPS that the Names in certificates
> (usually in section 3.1) don’t comply with the BRs
> > 3)      Ensure that the CPS clearly defines the rules for names (so the
> auditor can confirm that the issued certificates meet the rules)
> > 4)      Discuss this with each organization that requires following the
> BRs as part of accepting roots to their trust list
> > 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)
> > 6)      Then the auditor will include a very similar sentence in their
> opinion letter.
> >
> > 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.
> >
> > If others agree, I don’t think the Forum or the validation WG needs to
> consider this issue further.
> >
> > Thanks,
> > Peter
> >
> >> On Mar 4, 2017, at 5:55 PM, Kirk Hall via Public <public at cabforum.org>
> wrote:
> >>
> >> Great explanation, Peter - thanks.
> >>
> >>
> >>
> >> Gerv - maybe the BR rules came from X520?  file:///C:/Users/khall/
> Downloads/T-REC-X.520-201610-I!!PDF-E.pdf
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> 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?
> >>
> >>
> >>
> >> Li-Chun -- can you solve your problem simply by following the rules in
> BR 9.16.3?
> >>
> >>
> >>
> >> 9.16.3. Severability
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> 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 questions at cabforum.org and
> receiving confirmation that it has been posted to the Public Mailing List
> and is indexed in the Public Mail Archives available at
> https://cabforum.org/pipermail/public/ (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.
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Peter
> Bowen via Public
> >> Sent: Thursday, March 2, 2017 7:29 PM
> >> To: CA/Browser Forum Public Discussion List <public at cabforum.org>
> >> Cc: Peter Bowen <pzb at amzn.com>
> >> Subject: [cabfpub] Naming rules
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >>
> >> 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.”
> >>
> >>
> >>
> >> Li-Chun: Did I get this right?
> >>
> >>
> >>
> >> Others: Does this make the issue clearer?
> >>
> >>
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> _______________________________________________
> >>
> >> Public mailing list
> >>
> >> Public at cabforum.org
> >>
> >> https://cabforum.org/mailman/listinfo/public
> >>
> >> _______________________________________________
> >> Public mailing list
> >> Public at cabforum.org
> >> https://cabforum.org/mailman/listinfo/public
> >
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170309/0bea7151/attachment.html>