Re: [cabfpub] [cabfquest] BR 7.1.4.2.2.j Other Subject Attributes

[Geoff Keating via Public]

My response would be that the OU could be a single hyphen minus, but this does 
not mean ‘absent’ or ’none provided’, it means the organization unit’s name is 
‘-’.  (Perhaps other units are called ‘•’, ‘▷’, and ‘◆’.)

It’s definitely the case that 7.1.4.2.2j does not apply to 7.1.4.2.2i, this was 
intentional because we did not want to require CAs to verify the names of 
organization units.

> On Feb 19, 2019, at 6:30 PM, sts07065692...@ezweb.ne.jp wrote:
> 
> Thank you for your confirmation.
> 
> Is it possible that the value of OU of subject distinguished
> name in a BR subscriber certificate is a single hyphen minus,
> provided that the value satisfies conditions of 7.1.4.2.2.i?
> --
>  iida
> 
>> Hello,
>> 
>> Thank you for contacting the CA/B Forum. You are correct. 7.1.4.2.2.j
>> applies to Subject attributes other than those listed in .a through .i, and
>> the Baseline Requirements permit CAs to include Subject attributes that are
>> not defined in 7.1.4.2.2 (Note that different rules apply to EV).



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] Hotels for Cupertino meeting

[Geoff Keating via Public]

Hi All!

If you haven’t already booked your hotel for the Cupertino meeting, and you 
still want to go, I’m getting indications that the Juniper Hotel has run out of 
rooms for the conference code.  They may still have rooms but you may have to 
pay regular rate (or at least corporate rate) for some nights.

Other options that seem to have rooms at this time are:

Cupertino Hotel - this is across the street from Infinite Loop
Wild Palms Hotel, Maple Tree Inn - these are a short bike or scooter ride away, 
or Lyft or rent a car.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter

[Geoff Keating via Public]

I support Tim's comment.

I think the scope of this charter is much too restrictive.  For example, 
consider Baseline Requirements section 4.1.2 (“the CA SHALL obtain… an executed 
Subscriber Agreement”). I don’t think the working group charter would allow 
discussion of such a section; it doesn’t fall under any of the items 
specifically mentioned as part of the Scope, unless you’re going to try to call 
it a ‘CA operational practice’.

That raises another concern I have with the scope, which is that it is vague, 
and so likely to lead to unresolvable disputes.  For example, suppose someone 
proposes something like section 6.1.5.  I would say this is out of scope, but 
someone else might say this is part of the certificate profile. Or someone 
might propose something like section 6.1.7 saying it’s an operational practice 
of the CA; is it?

> On Feb 6, 2019, at 12:19 PM, Tim Hollebeek via Public  
> wrote:
> 
> My experience is the reverse.  IETF and groups with tight charters get bogged 
> down in constant discussions about charter revisions.  CABF has recently 
> fallen into the same trap and I don’t think it is a change for the better.  
> There are other SDOs I participate in where groups have operated for 10+ 
> years with the same charter, with no downsides other than the fact that they 
> spend their time discussing and working on the relevant issues instead of 
> re-chartering every time a new topic comes up.


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [cabfquest] [Ext] FUNDAMENTAL SSL RULE CHANGE REQUIRED

[Geoff Keating via Public]

> On 22 Oct 2018, at 9:42 pm, Ryan Sleevi  wrote:
> 
> On Tue, Oct 23, 2018 at 12:27 AM Geoff Keating  > wrote:
> [redirecting discussion to cabfpub]
> 
> Geoff,
> 
> While I'm always one to appreciate public discussion, I want to highlight that
> 1) A member already expressed concern with redirecting to our public list
> 2) Our bylaws make it clear that there's an established process - 6.2 - to 
> deal with questions and proposed responses, which occurs on the management 
> list. This was also mentioned earlier on the thread in the previous 
> discussion.
> 3) Our bylaws explicitly make it clear that these discussions happen on the 
> management@ list (5.1(d))
> 4) Our bylaws also state, in 5.1 "Members are strongly discouraged from 
> posting the text of Member Mail List messages to the Public Mail List without 
> the permission of the author or commenter.”

Oops!  Sorry about that.  I believe we have this discussion every time; what 
happens is that I expect it to work the way you mention above, but I also 
remember that last time I did it wrong, and so I do it the opposite way to the 
way I think is correct, in the hope that this time I’ll get it right, and I 
don’t, and the cycle repeats.

Frankly, our Bylaws are too complicated for me to operate reliably, and given 
that it seems like half of our discussions are about how we’re not properly 
following them, I do not feel I am alone in this.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [cabfquest] [Ext] FUNDAMENTAL SSL RULE CHANGE REQUIRED

[Geoff Keating via Public]

[redirecting discussion to cabfpub]

> On 22 Oct 2018, at 6:45 pm, Ryan Sleevi via Questions 
>  wrote:

> Thus if you want a certificate for a single hostname, the SAN must be <= 64 
> characters. If you want to have a certificate for a SAN > 64 characters, you 
> need to encode an additional SAN (that is <= 64 characters), or you need to 
> use OV/EV. Ballot 208 would have fixed that.

I think you misunderstand the purpose of ballot 208.  If you don’t want to use 
OV or EV, and you can’t fit any of the SANs in the commonName, you can just not 
provide a commonName; it’s optional!  But, the claimed reason for ballot 208 is 
that there is some software out there which can't support empty subjectName and 
also supported only specific subjectName fields and that some people wanted to 
use this software without validating any part of the certificate except for the 
hostname.  Oh, and they didn’t want to use countryName nor serialNumber nor 
[several other alternatives omitted]...

Now, there are a bunch of alternatives to work around the various 
problems/bugs/whatevers, but the overall principle is:

- If your software has a lot of bugs and problems and missing features,
- And you're pretty picky, you must have DV and you won't rename your host and 
so on,
- Then eventually you paint yourself into a corner and nothing works.

I’m not sure anything can really save people from that.

So, my answer to the original question (is there even a question there?) is:


Thank you for your question.  The commonName field in a certificate subjectName 
is optional.  If all the host names in the certificate are too long to fit in 
the commonName, it must be omitted.  The host names will be placed in the 
dNSName part of the subjectAlternativeName field.  All SSL clients should use 
the subjectAlternativeName field to match the host so it should not matter that 
the commonName field is not present.

Under some circumstances, this may lead to a completely empty subjectName, 
which may cause difficulties with some software.  If such problems are 
encountered, and the software cannot be upgraded, it is suggested to add 
validated information to the subjectName field, such as countryName and/or 
organizationName, producing an OV certificate.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Draft Bylaws 5.6 - Subcommittees of the CA/Browser Forum

[Geoff Keating via Public]

> On Oct 16, 2018, at 2:54 PM, Ryan Sleevi via Public  
> wrote:
> 
> Again, I'm afraid you're misunderstanding, but I can hope that members on the 
> list and following the discussion will not be confused.

As a member on the list and following the discussion, I have no idea what 
objections you actually have to the proposed wording.  My impression is that 
you think that perhaps the Bylaws will be changed in a way which leads to IPR 
consequences, but I cannot imagine what consequences you think there might be, 
nor can I see how having the form of a Working Group instead of a subcommittee 
makes any difference.

It is not clear to me that a Working Group can produce changes to the Bylaws.  
I would suggest that 5.3.3(a) might have been intended to be an exclusive 
description of the output of a Working Group.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Proposed Bylaws Sec. 5.3.1(f) - Default procedures for new Chartered Working Groups

[Geoff Keating via Public]

Although the details do need work, I support Kirk’s approach here, which is 
that the bylaws should contain a set of default rules which describe everything 
needed to operate a working group or a subcommittee, except for the name and 
scope.  It is much better if a motion to create a working group can be a few 
lines long, and focuses on the critical details of the working group, rather 
than having to be several pages of mostly boilerplate copied and pasted, 
perhaps incorrectly, from multiple sources.

> On Oct 16, 2018, at 1:55 PM, Ryan Sleevi via Public  
> wrote:
> 
> Kirk,
> 
> I'm afraid that wasn't my question, nor was it a suggestion.
> 
> It sounds like you haven't done what was discussed - an evaluation of the 
> bylaws. I'm hoping you can make a more compelling case that these will 
> address the issues. One way to make such a compelling case is to highlight 
> "The Bylaws require CWGs specify how to address X, Y, Z in their charters. 
> Here are samples we can use to address Y and Z in a generic way". This was 
> the path discussed as a positive step forward, and it does not appear this 
> does it.
> 
> For example, your proposal is clearly deficient and fails to address what was 
> discussed - such as how the formation of subcommittees is done, which the 
> Bylaws call for in 5.3.1(e). This is the problem with rushing to provide 
> language, and ignoring the discussions on possible paths forward - it easily 
> leads to avoidable mistakes.
> 
> On Tue, Oct 16, 2018 at 1:50 AM Kirk Hall  > wrote:
> Good point.  We can modify my language so the default provisions in my 
> proposal below would apply to new CWGs *and all subcommittees created by a 
> CWG”.  How does that sound to you?
> 
>  
> 
> Do you have any other edits to suggest?
> 
>  
> 
> From: Ryan Sleevi [mailto:sle...@google.com ] 
> Sent: Tuesday, October 16, 2018 1:46 PM
> To: Kirk Hall  >; CABFPub  >
> Subject: [EXTERNAL]Re: [cabfpub] Proposed Bylaws Sec. 5.3.1(f) - Default 
> procedures for new Chartered Working Groups
> 
>  
> 
>  
> 
> Thanks for proposing this.
> 
>  
> 
> It does not seem to address some of the other topics that were discussed, 
> such as the formation of subcommittees.
> 
>  
> 
> We left the discussion with a call to provide a methodical analysis of where 
> the bylaws defer to a CWGs charter, to provide better example guidance. Have 
> you done this? It might be better to start from there, rather than proposing 
> ballot text immediately following such discussions, so that we can actually 
> have confidence that the issues are being addressed.
> 
>  
> 
> On Tue, Oct 16, 2018 at 1:43 AM Kirk Hall via Public  > wrote:
> 
> As we discussed this morning, we need certain “default” procedures for how 
> *new* Working Groups operate, which could (in theory) be specifically 
> overridden by the Forum by passing *different* procedures for a particular 
> CWG in the charter of a new Chartered Working Group (CWG). 
> 
>  
> 
> It is unlikely that we would ever override these standard Bylaws provisions 
> for an individual CWG charter, but it would be possible. 
> 
>  
> 
> A CWG could also adopt *additional* procedures for its CWG by a CWG ballot if 
> it wants to, so long as the additional procedures do not conflict with the 
> CWG charter and/or Bylaw Sec. 5.3.1(f).
> 
>  
> 
> So this is a potential Forum ballot to amend the Bylaws – please comment:
> 
>  
> 
>  
> 
> Bylaws Sec. 5.3.1 - Formation of Chartered Working Groups ***
> 
>  
> 
> (f) Unless otherwise specifically provided in the charter of a CWG, a CWG 
> shall be governed by the following rules:
> 
>  
> 
> 1.   Each CWG shall have a Chair and Vice Chair who shall be elected by 
> CWG members following the procedures of Bylaws Section 4.1 as closely as 
> possible.  The initial term for CWG officers shall expire on November 30 of 
> the next even-numbered year after the CWG is established to be synchronized 
> with the terms of Forum officers.
> 
>  
> 
> 2.   Proposing and voting on CWG Ballots by CWG members shall follow the 
> procedures stated in Bylaws Sec. 2.3 and 2.4.
> 
>  
> 
> * * * * *
> 
>  
> 
> [Note: Bylaws Sec. 5.2 already requires CWGs to post Agendas, Minutes, and 
> Ballots to the Public lists – see below -  so I don’t think we need more 
> default provisions on those subjects.   LWG means Legacy Working Group, and 
> all Legacy Working Groups have expired.]
> 
>  
> 
> Bylaws Sec. 5.2 - Public Mail List and Public Web Site [Existing language]
> 
>  
> 
> The Chair shall appoint a List Manager who shall maintain a Public Mail List. 
> Members and Interested Parties may post to the Public Mail List in compliance 
> with these Bylaws. Anyone else is allowed to subscribe to and receive 
> messages posted to the Public Mail List, which may be crawled and indexed by 
> 

Re: [cabfpub] Public Digest, Vol 77, Issue 81

[Geoff Keating via Public]

I think we’re in agreement as to the effect of not having minutes on the IPR 
policy.

I don’t believe anyone is proposing a subcommittee charter which *prevents* it 
from having minutes.  So, perhaps if you’re concerned that a subcommittee might 
not have the standard of minute-taking that you would like, you could offer to 
take minutes for that subcommittee?  My experience is that such an offer is 
usually received with gratitude!

> On Sep 14, 2018, at 2:04 PM, Ryan Sleevi via Public  
> wrote:
> 
> Please review section 8 of the IPR policy with your legal counsel, Tim, 
> particularly around what constitutes a "Contribution"
> 
> On Fri, Sep 14, 2018 at 4:52 PM Tim Hollebeek  > wrote:
> We have the protections in the IPR policy, because we have the IPR policy.  
> To be clear, the existence or absence of minutes does not in any way affect 
> the IPR policy, and there’s no text in the Bylaws or IPR policy that suggests 
> that it does.
> 
>  
> 
> -Tim
> 
>  
> 
> From: Public  > On Behalf Of Ryan Sleevi via Public
> Sent: Friday, September 14, 2018 4:41 PM
> To: Virginia Fournier mailto:vfourn...@apple.com>>; 
> CABFPub mailto:public@cabforum.org>>
> Subject: Re: [cabfpub] Public Digest, Vol 77, Issue 81
> 
>  
> 
> Virginia,
> 
>  
> 
> I do not understand how that position is at all consistent with our bylaws 
> with respect to IP risk. If we have Subcommittees without the requirement to 
> maintain or produce minutes, how could we possibly hope to have the IP 
> protections afforded by our policy?
> 
>  
> 
> On Fri, Sep 14, 2018 at 4:32 PM Virginia Fournier via Public 
> mailto:public@cabforum.org>> wrote:
> 
> It would be great if the people who continually complain that the Bylaws 
> don’t contain x, or took away y, would actively participate in the process to 
> create new versions of the Bylaws.  The version of the Bylaws creating CWGs 
> and their Subcommittees was developed over more than a year, with ample time 
> for review, comment, revision, rinse and repeat.
> 
>  
> 
> The Bylaws say that "each CWG may establish any number of subcommittees 
> within its own Working Group to address any of such CWG’s business.” However, 
> there's nothing in the Bylaws that prohibits Subcommittees from having their 
> own mailing lists, minutes, chairs, etc.  It looks like Subcommittees have 
> the   flexibility to determine how to conduct their own business within the 
> CWG.  
> 
>  
> 
> If a CWG wants a Subcommittee to do something specific (like keep minutes), 
> they can specify that in the CWG charter.   
> 
>  
> 
> Best regards,
> 
>  
> 
> Virginia Fournier
> 
> Senior Standards Counsel
> 
>  Apple Inc.
> 
> ☏ 669-227-9595
> 
> ✉︎ v...@apple.com 
>  
> 
>  
> 
>  
> 
> On Sep 14, 2018, at 9:29 AM, public-requ...@cabforum.org 
>  wrote:
> 
>  
> 
> Send Public mailing list submissions to
> public@cabforum.org 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://cabforum.org/mailman/listinfo/public 
> 
> or, via email, send a message with subject or body 'help' to
> public-requ...@cabforum.org 
> 
> You can reach the person managing the list at
> public-ow...@cabforum.org 
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Public digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Ballot SC10 ? Establishing the Network Security
>  Subcommittee of the SCWG (Ryan Sleevi)
>   2. Re: Ballot SC10 ? Establishing the Network Security
>  Subcommittee of the SCWG (Tim Hollebeek)
> 
> 
> --
> 
> Message: 1
> Date: Fri, 14 Sep 2018 12:19:24 -0400
> From: Ryan Sleevi mailto:sle...@google.com>>
> To: Tim Hollebeek  >
> Cc: CABFPub mailto:public@cabforum.org>>
> Subject: Re: [cabfpub] Ballot SC10 ? Establishing the Network Security
> Subcommittee of the SCWG
> Message-ID:
>  >
> Content-Type: text/plain; charset="utf-8"
> 
> Subcommittees don't have requirements for minutes or publicly-available
> notes.
> 
> That's the point. All this thinking about subcommittees working "just like"
> LWGs is not the case. All of that was lost from the Bylaws. A subcommittee
> can just be two people having a chat, at least as written in the Bylaws
> today.
> 
> There's nothing stating subcommittees work with their own mailing lists,
> for example, in the way our old bylaws did. There's nothing establishing
> chairs or charters or deliverables. It's a one-off note.
> 
> That's the point.
> 
> On Fri, Sep 14, 2018 at 12:13 PM Tim Hollebeek  >
> wrote:
> 
> 
> 
> Collaborating 

Re: [cabfpub] [Servercert-wg] Ballot SC4 - email and CAA CONTACT

[Geoff Keating via Public]

> On 8 Aug 2018, at 7:42 pm, Ryan Sleevi via Servercert-wg 
>  wrote:
> 
> 
> On Wed, Aug 8, 2018 at 10:30 PM Tim Hollebeek  > wrote:
> From: mailto://tim.holleb...@digicert.com 
> 
> To: mailto://sle...@google.com 
>  
> 
> To make it clear, I don’t think turning things into URIs adds value for 
> customers.  E-mail addresses usually AREN’T in the form of URIs, as noted 
> above.
> 
> 
> Except, again, this is dodging the point that Corey raised, and which you 
> haven't at all addressed, in which you're proposing a form that leaves it 
> entirely ambiguous to the CA, and subjective to their interpretation, as to 
> the form - and ambiguous for customers.
> 
> If your view is that you're being customer focused, then that's not really 
> sustained by any of the positions being advocated here. The ambiguity you're 
> arguing is a strength is going to lead to misissued certificates and confused 
> customers.

I would encourage mailing list participants to remember that writing a ballot 
is a valuable contribution to the CABforum, and we should remember that list 
participants may have different strengths and not always be able to come up 
with perfect wording covering, for example, e-mail addresses as they have been 
developed over 40 years of the Internet.  At no point in this discussion has 
anyone actually proposed better wording than ‘valid e-mail address’ and so I 
really don’t think it’s fair to make comments like the above.

If it’s desired to further clarify, I would say ‘valid e-mail address as 
defined in RFC 5321 section 2.3.11’.  However I think this is unnecessary.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Servercert-wg] Ballot SC3: Improvements to Network Security Guidelines

[Geoff Keating via Public]

> On 20 Jul 2018, at 1:41 pm, Mike Reilly (GRC) via Public 
>  wrote:
> 
> Hi Tim S.  What the last point I made about the use of Just In Time (JIT) 
> admin where all CA access is done with a session password that is deleted 
> when the session ends. So we literally have passwords that last minutes. Once 
> the session ends the password is useless.  That would be a CA policy 
> requiring the password to change based on it’s age, which would be measured 
> in minutes.  Thanks, Mike

That wouldn’t be a ‘periodic’ change, because the password isn’t changed, it’s 
deleted, and because it only happens once.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] On the use of misuse - and the necessity to remove it

[Geoff Keating via Public]

> On Jun 7, 2018, at 1:40 PM, Ryan Sleevi via Public  
> wrote:
> 
> In the pursuit of a definition, we tried to work backwards - what are 
> situations we think are misuse.

The dictionary definition of ‘misuse’ is:

use (something) in the wrong way or for the wrong purpose

> Another suggestion was that it involved scenarios where the Subscriber 
> private key was in an HSM, and itself was not compromised, but had signed 
> things it was not expected to. This wasn't elaborated on further - so I'm 
> uncertain if this meant things other than the TLS handshake transcript - but 
> this is already met by our definition of Key Compromise in 1.6.1, that is:
> ""A Private Key is said to be compromised if its value has been disclosed to 
> an
>unauthorized person, an unauthorized person has had access to it, or there 
> exists a
>practical technique by which an unauthorized person may discover its 
> value. “""

If a key is in a HSM and not exportable, then its value is not disclosed, nor 
does an unauthorized person have access *to the key*.  Dictionary definition of 
‘access’ is 'obtain, examine, or retrieve’ none of which apply here.  So it is 
not covered by Key Compromise.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] How do you handle mass revocation requests?

[Geoff Keating via Public]

> On 28 Feb 2018, at 11:08 am, Ryan Sleevi <sle...@google.com> wrote:
> 
> 
> 
> On Wed, Feb 28, 2018 at 1:59 PM, Geoff Keating via Public 
> <public@cabforum.org> wrote:
>> This raises a question about the MDSP policy and CAB Forum requirements. Who 
>> is the subscriber in the reseller relation?  We believe this to be the key 
>> holder. However, the language is unclear.
> 
> ‘Subscriber’ is a defined term in the BRs:
> Subscriber: A natural person or Legal Entity to whom a Certificate is issued 
> and who is legally bound by a Subscriber Agreement or Terms of Use.
> 
> That’s pretty clear and can’t be stretched to cover a reseller—a reseller 
> won’t be able to comply with a Subscriber Agreement.
> 
> At the risk of stretching things, I want to point out that taking this 
> interpretation requires determining whether or not the Reseller is acting as 
> an Applicant Representative during the process.
> 
> In this case, is the Reseller legally binding the "user" (for lack of better 
> word) to a Subscriber Agreement? If so, how does the CA determine that the 
> Reseller is an authorized Applicant Representative, and thus entitled to 
> legally bind the "user" to the Subscriber Agreement?

There are several ways this could be done.  However there is no question about 
the result, because that’s covered by 4.1.2:
Prior to the issuance of a Certificate, the CA SHALL obtain the following 
documentation from the Applicant:

• A certificate request, which may be electronic; and

• An executed Subscriber Agreement or Terms of Use, which may be 
electronic 

So after a CA issues the certificate, it’s easy to find out who the Subscriber 
was (for some definition of ‘who’): you get the CA’s copy of the Subscriber 
Agreement and look for the bit where it says “This is an agreement between 
__ and .” and see what was written in the blank.  (and yes, it does 
have to be between the Subscriber and the CA, not between the Subscriber and 
anyone else, see the definition of ’Subscriber Agreement’.)

In addition under 9.6.1 item 6, the CA ‘represents and warrants’ that “the 
Subscriber and CA are parties to a legally valid and enforceable Subscriber 
Agreement that satisfies these Requirements…” and under 9.6.3, "The CA SHALL 
implement a process to ensure that each Subscriber Agreement or Terms of Use is 
legally enforceable against the Applicant."

> That is, I can see several models of Reseller being done by CAs, so it's... 
> perhaps nuanced
> - One model is that the Reseller performs all the interaction with the CA, 
> acting as an "Applicant Representative" of sorts
>   - That is, Reseller may say "User is ID_X", and then directly talks to the 
> CA on the user's behalf, saying "User that I call ID_X has agreed to your 
> Subscriber Agreement" - without demonstration of proof, necessarily.
> - Another model is that the Reseller "introduces" the "user" to the CA. The 
> CA has a notion and binding directly with the user (who themselves may be an 
> Applicant Representative of a Legal Entity), and the Reseller has a 
> _separate_ notion - which may be further linked to the CAs' notion, but are 
> otherwise kept separate.
>   - That is, Reseller may say "User is ID_X", introduces them to CA and says 
> "I call them ID_X", the CA assigns "ID_1", and records that if it needs to 
> communicate with the Reseller again (e.g. for billing/recovery), "ID_1 == 
> ID_X". The CA always has direct exchange with the user.
>  
> Looking at the reseller/integration APIs that CAs have shared in the past, I 
> understand both models are deployed and in use, thus some degree of ambiguity.
> 
> In the first case, where the user always talks to Reseller and Reseller 
> always talks to CA, I would argue that the Reseller is likely the Subscriber, 
> and CAs are playing shellgames if they claim otherwise. I don't think this is 
> necessarily bad (consider that hosting providers that terminate TLS 
> themselves generally fall into this bucket).

In this first case, the Reseller has to be either part of the CA, or a 
Designated Third Party, because they’re doing things that the CA has to do 
(compliance with 9.6.3, for example).

>  In the second case, I think we've got a clearer separation that the "user" 
> is the true Subscriber - because the CA can demonstrate they're legally bound 
> (for some value) - and the Reseller is just a random nobody.

That can happen.  Sometimes resellers really have nothing to do with the 
certificate issuance process.

>> At this time, Trustico has not provided any information about how these 
>> certificates were compromised or how they acquired the private keys.

Re: [cabfpub] How do you handle mass revocation requests?

[Geoff Keating via Public]

> This raises a question about the MDSP policy and CAB Forum requirements. Who 
> is the subscriber in the reseller relation?  We believe this to be the key 
> holder. However, the language is unclear.

‘Subscriber’ is a defined term in the BRs:
Subscriber: A natural person or Legal Entity to whom a Certificate is issued 
and who is legally bound by a Subscriber Agreement or Terms of Use.

That’s pretty clear and can’t be stretched to cover a reseller—a reseller won’t 
be able to comply with a Subscriber Agreement.

> At this time, Trustico has not provided any information about how these 
> certificates were compromised or how they acquired the private keys.

One question I would have is whether Trustico is in compliance with 6.1.2, 
"Parties other than the Subscriber SHALL NOT archive the Subscriber Private Key 
without authorization by the Subscriber.”

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

> On Jan 23, 2018, at 12:50 PM, Jonathan Rudenberg via Public 
>  wrote:
> 
> 
>> On Jan 23, 2018, at 14:36, Bruce Morton  
>> wrote:
>> 
>> Hi Jonathan, 
>> 
>> Please note that the domain validation methods under BR 3.2.2.4 are 
>> introduced as follows:  "This section defines the permitted processes and 
>> procedures for validating the Applicant's ownership *or* control of the 
>> domain."  There is no requirement of proving both domain ownership and 
>> control, and proving only domain control has its own security 
>> vulnerabilities.
> 
> The method you’ve described does not establish domain ownership either. All 
> it establishes it that you asked for an attacker-controlled name at a phone 
> number from a potentially attacker-controlled third-party database record 
> that matches some fields in the WHOIS data.
> 
>> Finally we do 3.2.5, the authorization to issue check. We do not use the 
>> information from WHOIS to perform this check. The reason is most information 
>> is provided by the Registrant, so using it would be considered allowing 
>> self-validation. This information may be OK to use to show domain control, 
>> but should not be used for authorization to issue. As such, we call the 
>> Applicant, which also owns the domain to confirm authorization to issue. You 
>> say that the Applicant Authorization Contact does not control the domain and 
>> you are probably right. Actually, we think that the Applicant Technical 
>> Contact controls the domain. We don't want to contact the Applicant 
>> Technical Contact as again, this would be self-verification. Also, in many 
>> cases, the Applicant Technical Contact is a contractor or hoster and should 
>> not verify authorization to issue. We use a phone number found in a QIIS to 
>> contact the Applicant. This verifies that the Applicant Authorization 
>> Contact is employed by the Applicant and the CA relies on their authority.
> 
> There are a lot of assumptions being made here that don’t fit the adversarial 
> threat model of the WebPKI. Just because someone is routable via an arbitrary 
> phone number does not indicate that they are the domain owner or even 
> employed by the entity that you believe is associated with the phone number.

Yes.  Many companies have publicly accessible phones which can be reached from 
their central switchboard—emergency phones, publicly accessible conference room 
phones, that kind of thing.  So all you have to do is get to one of them, call 
up the switchboard, and say “I’m expecting a call from XXX, and I’m here in 
this conference room, can you put it through?”.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

> On Jan 19, 2018, at 12:16 PM, Kirk Hall  wrote:
> 
> Sorry for the misquotation – I left off “*** directly with the Domain Name 
> Registrar,” which is generally what we have been discussing – a WhoIs lookup 
> to see who owns the domain.

That wasn’t my objection—it was to the words “by verifying that”.

> But do you see my point that “validating the Applicant as the Domain Contact” 
> (current language) could simply be confirming a hacker in both roles, but 
> would not be validating the Registrant information as to the organization 
> that owns the domain? 
> 
> Which would not be sufficient to include the Registrant Organization name in 
> the O field of an OV or EV cert.   That’s why we made the change, which makes 
> Method 1 more secure in our opinion.

Are some CAs validating by saying that, for example, someone has control of 
cabforum.org and so based only on that and the whois information they can be 
issued a certificate with O=Go Daddy?  That would be unfortunate.

As a side note, do you think it would be helpful to put something in the BRs to 
basically say “you still have to validate everything in a certificate; if these 
BRs appear to allow a process which is not an effective validation, or some 
choices in your implementation of the process makes it ineffective, you must do 
whatever additional process is necessary to ensure an effective validation”?  
An overall “don’t be stupid” rule.

> Again, Method 1 was the original validation method starting in the 1990s, and 
> I think it’s proven its worth over the years.

Processes often work great until someone works out how to abuse them, and then 
they don’t, sadly.

>  
> From: geo...@apple.com [mailto:geo...@apple.com] 
> Sent: Friday, January 19, 2018 11:52 AM
> To: Kirk Hall 
> Cc: CA/Browser Forum Public Discussion List ; Mads Egil 
> Henriksveen 
> Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain 
> Authorization Document
>  
>  
> 
> 
> On Jan 19, 2018, at 11:23 AM, Kirk Hall  > wrote:
>  
> First, I think everyone knows what CAs are supposed to do under Method 1
>  
> I’m fairly sure this is not the case…
> 
> 
> , and the lack of misissuance reports means CAs are doing it right.  Here’s 
> how Method 1 starts now:
>  
> “Conforming the Applicant's control over the FQDN by validating the Applicant 
> as the Domain Contact by verifying that: ***”
>  
> You can see why I think CAs might not know what they’re supposed to do, 
> because the above quote is not the actual words from the the Baseline 
> Requirements!  Right now, in BR 1.5.4, Method 1 starts with these words:
>  
> Confirming the Applicant's control over the FQDN by validating the Applicant 
> is the Domain Contact directly with the Domain Name Registrar. This method 
> may only be used if:
>  
> Your version prescribes a method.  The actual current requirements specify an 
> objective and don’t specify a method.
>  
> Now, I’m not against prescribing a method, but the method prescribed does 
> need to achieve the original objective, and I think the proposed method is 
> inadequate to do that…

___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

> On Jan 19, 2018, at 11:23 AM, Kirk Hall  wrote:
> 
> First, I think everyone knows what CAs are supposed to do under Method 1

I’m fairly sure this is not the case…

> , and the lack of misissuance reports means CAs are doing it right.  Here’s 
> how Method 1 starts now:
>  
> “Conforming the Applicant's control over the FQDN by validating the Applicant 
> as the Domain Contact by verifying that: ***”

You can see why I think CAs might not know what they’re supposed to do, because 
the above quote is not the actual words from the the Baseline Requirements!  
Right now, in BR 1.5.4, Method 1 starts with these words:

> Confirming the Applicant's control over the FQDN by validating the Applicant 
> is the Domain Contact directly with the Domain Name Registrar. This method 
> may only be used if:

Your version prescribes a method.  The actual current requirements specify an 
objective and don’t specify a method.

Now, I’m not against prescribing a method, but the method prescribed does need 
to achieve the original objective, and I think the proposed method is 
inadequate to do that…



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

The ‘Domain Contact’ is not just a name.  For example, for cabforum.org 
<http://cabforum.org/>, it’s all of this data:

Registrant Name: Domain Administrator
Registrant Organization: Go Daddy Operating Company, LLC
Registrant Street: 14455 N Hayden Rd Suite 219
Registrant City: Scottsdale
Registrant State/Province: Arizona
Registrant Postal Code: 85260
Registrant Country: US
Registrant Phone: +1.4805058800
Registrant Phone Ext:
Registrant Fax: +1.4805058844
Registrant Fax Ext:
Registrant Email: companyna...@godaddy.com

It’s “self-reported”, but not by the Applicant; it’s reported by the actual 
domain name owner.  This data is what has to be matched against the 
Applicant—you need to confirm that the Applicant will respond when contacted 
using this information.


I’m not sure about limiting this to just the Registrant.  The registrant is the 
‘owner’ of the domain, but wouldn't the technical contact be likely to have 
control over the domain?  (That’s almost the definition of who you put as the 
technical contact.)

> On Jan 19, 2018, at 10:33 AM, Kirk Hall <kirk.h...@entrustdatacard.com> wrote:
> 
> Jeff - here are the three relevant definitions:
>  
> Applicant: The natural person or Legal Entity that applies for (or seeks 
> renewal of) a Certificate. Once the Certificate issues, the Applicant is 
> referred to as the Subscriber.
>  
> Domain Contact: The Domain Name Registrant, technical contact, or 
> administrative contract (or the equivalent under a ccTLD) as listed in the 
> WHOIS record of the Base Domain Name or in a DNS SOA record.
>  
> Domain Name Registrant: Sometimes referred to as the “owner” of a Domain 
> Name, but more properly the person(s) or entity(ies) registered with a Domain 
> Name Registrar as having the right to control how a Domain Name is used, such 
> as the natural person or Legal Entity that is listed as the “Registrant” by 
> WHOIS or the Domain Name Registrar.
>  
> "Domain Contact" is just the self-reported name in WhoIs -- so I think Domain 
> Name Registrant is the party we are actually trying to verify as the 
> Applicant.
>  
> -Original Message-
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Geoff Keating 
> via Public
> Sent: Friday, January 19, 2018 10:18 AM
> To: Mads Egil Henriksveen <mads.henriksv...@buypass.no>; CA/Browser Forum 
> Public Discussion List <public@cabforum.org>
> Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain 
> Authorization Document
>  
> I think this proposed change actually makes 3.2.2.4.1 weaker.  Previously it 
> was necessary to validate that the Applicant and the Domain Contact were the 
> same—some CAs might not have been doing this properly, but it was what the 
> words said.  Now you’re just validating that the Applicant has the same name 
> and represents to a Q*IS that it has the same address.
>  
> > On Jan 19, 2018, at 4:58 AM, Mads Egil Henriksveen via Public 
> > <public@cabforum.org <mailto:public@cabforum.org>> wrote:
> > 
> > Hi Gerv
> > 
> > The current version 3.2.2.4.1 says:
> > 
> > 3.2.2.4.1 Validating the Applicant as a Domain Contact Confirming the
> > Applicant's control over the FQDN by validating the Applicant is the Domain 
> > Contact directly with the Domain Name Registrar.
> > 
> > This method may only be used if:
> > 1. The CA authenticates the Applicant's identity under BR Section
> > 3.2.2.1 and the authority of the Applicant Representative under BR
> > Section 3.2.5, OR 2. The CA authenticates the Applicant's identity under EV 
> > Guidelines Section 11.2 and the agency of the Certificate Approver under EV 
> > Guidelines Section 11.8; OR 3. The CA is also the Domain Name Registrar, or 
> > an Affiliate of the Registrar, of the Base Domain Name.
> > 
> > Note: Once the FQDN has been validated using this method, the CA MAY also 
> > issue Certificates for other FQDNs that end with all the labels of the 
> > validated FQDN. This method is suitable for validating Wildcard Domain 
> > Names.
> > -
> > 
> > Our proposal concentrates on the first part, i.e. the following statement:
> >>> Confirming the Applicant's control over the FQDN by validating the 
> >>> Applicant is the Domain Contact directly with the Domain Name Registrar.
> > 
> > Is to be replaced with:
> > << Conforming the Applicant's control over the FQDN by validating the 
> > Applicant as the Domain Name Registrant by verifying that:
> > << 1.  The name of the Domain Name Registrant matches the Applicant's name 
> > AND
> > << 2.  Additional information about the Domain Name Registrant i

Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

I think this proposed change actually makes 3.2.2.4.1 weaker.  Previously it 
was necessary to validate that the Applicant and the Domain Contact were the 
same—some CAs might not have been doing this properly, but it was what the 
words said.  Now you’re just validating that the Applicant has the same name 
and represents to a Q*IS that it has the same address.

> On Jan 19, 2018, at 4:58 AM, Mads Egil Henriksveen via Public 
>  wrote:
> 
> Hi Gerv
> 
> The current version 3.2.2.4.1 says:
> 
> 3.2.2.4.1 Validating the Applicant as a Domain Contact
> Confirming the Applicant's control over the FQDN by validating the Applicant 
> is the Domain Contact directly with the Domain Name Registrar. 
> 
> This method may only be used if:
> 1. The CA authenticates the Applicant's identity under BR Section 3.2.2.1 and 
> the authority of the Applicant Representative under BR Section 3.2.5, OR
> 2. The CA authenticates the Applicant's identity under EV Guidelines Section 
> 11.2 and the agency of the Certificate Approver under EV Guidelines Section 
> 11.8; OR
> 3. The CA is also the Domain Name Registrar, or an Affiliate of the 
> Registrar, of the Base Domain Name.
> 
> Note: Once the FQDN has been validated using this method, the CA MAY also 
> issue Certificates for other FQDNs that end with all the labels of the 
> validated FQDN. This method is suitable for validating Wildcard Domain Names.
> -
> 
> Our proposal concentrates on the first part, i.e. the following statement: 
>>> Confirming the Applicant's control over the FQDN by validating the 
>>> Applicant is the Domain Contact directly with the Domain Name Registrar.
> 
> Is to be replaced with:
> << Conforming the Applicant's control over the FQDN by validating the 
> Applicant as the Domain Name Registrant by verifying that: 
> << 1. The name of the Domain Name Registrant matches the Applicant's name AND
> << 2. Additional information about the Domain Name Registrant in the WHOIS 
> meet the following requirements:
> <<  i.The Registrant's postal address in the WHOIS belongs to 
> the Applicant. CAs MUST verify this by matching it with one of the 
> Applicant's addresses in: (a) a QGIS, QTIS, or QIIS; or (b) a Verified 
> Professional Letter. 
> << Note: Address details in the WHOIS are required to 
> use this option. Address details must include at a minimum the Country and 
> either Locality, State or Province. OR 
> <<  ii.   The WHOIS contains the Registration (or similar) Number 
> assigned to the Applicant by the Incorporating or Registration Agency in its 
> Jurisdiction of Incorporation or Registration as appropriate. CAs MUST verify 
> this by matching the Registration Number in the WHOIS with the Applicant's 
> Registration Number in a QGIS or a QTIS.
> 
> The first change is the use of Domain Name Registrant instead of Domain 
> Contact, i.e. the focus is on domain ownership. 
> 
> The proposal requires that the name of the Registrant (in WHOIS) matches 1) 
> the name of the Applicant AND either 2 i) the postal address of the 
> Registrant (in WHOIS) matches the postal address of the Applicant (in sources 
> accepted for EV validation) OR 2 ii) a Registration Number for the Registrant 
> (in WHOIS) matches the Registration Number of the Applicant (in a QGIS or 
> QTIS).
> 
> The proposal addresses threats due to that organization names are not unique, 
> the combination of organization name and address or organization name and 
> registration number should be unique. It also removes ambiguities the current 
> language permits (according to Jeremy - see attachment). 
> 
> Regards
> Mads 
> 
> -Original Message-
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase 
> Markham via Public
> Sent: fredag 19. januar 2018 10:29
> To: Mads Egil Henriksveen via Public 
> Subject: Re: [cabfpub] [EXTERNAL] Verification of Domain Contact and Domain 
> Authorization Document
> 
> On 19/01/18 06:51, Mads Egil Henriksveen via Public wrote:
>> Buypass, Entrust Datacard and GlobalSign have been working on some 
>> text to strengthen 3.2.2.4.1 instead of removing it - find the draft 
>> text below. The draft was discussed in the Validation Working Group 
>> meeting yesterday. We would like to offer this as an amendment to Ballot 218.
> 
> Is it possible to provide a diff, e.g. by turning the new text into a Github 
> pull request, or some other mechanism?
> 
> Once we have a diff, might it be possible for rationale to be provided for 
> each change?
> 
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature

Re: [cabfpub] Restrict certificate lifetime to domain registration period (if certificate expiry date is greater than domain registration)

[Geoff Keating via Public]

> On Jan 11, 2018, at 2:56 PM, James Burton via Public  
> wrote:
> 
> Shouldn't we start restricting the certificate lifetime to domain 
> registration period if the certificate expiry date is greater than domain 
> registration period?

Sometimes the domain registration will be extended close to its expiry, a few 
weeks before or even exactly on the expiry date—for example, with most kinds of 
autorenewal system.  That won’t give enough time to obtain, install, and test a 
replacement certificate.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Verification of Domain Contact and Domain Authorization Document

[Geoff Keating via Public]

> On Dec 22, 2017, at 12:09 PM, Jeremy Rowley via Public  
> wrote:
> 
> The attack vector is easier than that. 
> I use very stringent processes to verify that Google, Inc. is a legit company 
> in Utah.
> I verify that Jeremy did indeed incorporate Google, Inc. 
> I call Jeremy at the phone listed for Google, Inc., the Utah corporation
> The domain information shows Google, Inc. as owning google.com 
> 
> Certificate issues.
>  
> Obviously this would be caught in every CA’s high risk checks, but the point 
> remains valid. Regardless of the expertise and thoroughness of the org check, 
> the specs lack any time between the verified org and the actual domain 
> because orgs are not unique on a global basis.
>  

For item 4, you have to verify that “the Applicant is the Domain Contact”.  
Obviously it’s insufficient to just compare names—you must verify every element 
of the WHOIS contact matches the Applicant, that’s typically name, postal 
address, phone number, and e-mail.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing

[Geoff Keating via Public]

> On 4 Dec 2017, at 12:51 pm, Kirk Hall  wrote:
> 
> Geoff, a few quick responses to your points below:
> 
> 1. I think you are proposing the CA confirm the address information by 
> sending (mail, delivery) a confirmation message with a shared secret to the 
> customer, and requiring a response back using the shared secret.  I think 
> that's a good idea - it might get problematic for a big company (for Apple, 
> we might have to mail to you at 1 Infinity Loop - how long would it take for 
> you to receive it?).

No—this section is verification of ‘Applicant’s Physical Existence’, so this 
would be (i)(2), a site visit confirming such things as permanent signage.  The 
ability to receive mail is not what that section is trying to check; drop 
boxes, PO boxes, and such are not good enough.

> 2.  We can also require a Face-to-Face requirement to discourage potential 
> fraudsters, maybe limited to companies less than 1 year old (less than 6 
> months old?) and with net worth (as reported in a third party business data 
> source) of less than $1 million (?) - financial estimates like that are made 
> by the third party data source, and are not self-reported.  Maybe we also 
> should limit the mailing address confirmation the same way - only require for 
> companies that are less than 1 year old (6 months old?) and with new worth 
> (as reported in a third party business data source) of less than $1 million.  

Again, I’m not sure what a face-to-face would be verifying.  This isn’t about 
existence of the person, it’s about the business.

> 3.  Geoff, while it's true that third party data sources will start with 
> self-reported data (like name and address), the rest of the data they use is 
> typically compiled by the third party data source, not just from 
> self-reported data or copied from public government data bases.

Yes… but we don’t require any of that other data, just the name and address.

>  Remember, the main customers of Hoover's and D are using the data to make 
> major credit decisions, not just to confirm addresses or incorporation 
> status, and the third party data sources use their own data (including credit 
> reporting from vendors who work with the subject company) and their own 
> anti-fraud algorithms to avoid broadcasting false data.  

Well, maybe we could require an actual credit check, then?  Or at least 
existence of a bank account?  Banks are required to do their own verification 
so I’d think the existence of a bank account with that address should count for 
something.  But a bank usually won’t release the physical address, only the 
mailing address…



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing

[Geoff Keating via Public]

> On 29 Nov 2017, at 9:44 am, Wayne Thayer via Public  
> wrote:
> 
> The EV process is intended to gather a robust body of information about the 
> Subject that, when viewed collectively, "provides users with a trustworthy 
> confirmation of the identity of the entity". James and later Ryan have 
> pointed out a weakness in the standard where incorrect data from a single 
> data source (QGIS) could be used to obtain a "properly validated" EV 
> certificate containing that incorrect data.
> 
> A positive outcome from this discussion would be for the Validation WG to 
> review this information and propose changes to the EVGLs (such as a 
> requirement for face-to-face validation mentioned by Jeremy) that mitigate 
> this weakness.

I’m not sure how face-to-face validation helps here, other than it means the 
applicant now has a chance to lie to your face, which at least adds a personal 
touch…

I understand that the flaw being discussed is that the physical address data 
reported by QGISs/etc. may be self-reported by the entity and not immediately 
(or ever) validated.   That seems like a problem, and really strikes at the 
heart of the 11.4.1(A) address verification.  Unless it can be fixed I would 
think we have to remove those methods and leave just (i)(2), (2), and (3).  [It 
would be nice if we could renumber this section so that it did not go (i)(1) 
(i)(2) (2) (3) (4).]

Is there any way we can make such a check reliable?  Some methods I have 
thought of that won’t work are:

- There could be an aging requirement, on the grounds that a renewal notice is 
sent—but if the renewal is paid anyway, perhaps online, we’d be relying on the 
letter being returned undeliverable and the Registration Authority noticing 
this fact, which seems unreliable.
- It seems like all the various information sources copy each other so we can’t 
rely on multiple sources.
- If any information sources actually validate the data, they don’t seem to say 
so, so it’s probably useless to require use of only information sources that 
say they validate the address.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Path forward for DV cert subjects

[Geoff Keating via Public]

> On 3 Nov 2017, at 2:37 pm, Peter Bowen via Public  wrote:
…
> From the discussion on the list, I propose that we explicitly exclude 
> countryName from Subject Identity Information.  As Geoff pointed out, 
> historically some DV certs have included countryName and there is a process 
> in the BRs for validation of countryName when it is the only item in the 
> subject.
> 
> What do others think?  Is it reasonable to allow DV certificates with 
> countryName in the subject?

I guess it should also be mentioned that if you use the process in the BRs, 
you’re not really validating that the countryName is the country of the 
subscriber; in this case the countryName is the country of a domain name or IP 
address.  It’ll be a country associated with the subscriber but not necessarily 
the subscriber's home.  So I think it would be reasonable to exclude it from 
Subject Identity Information.

If we were up for some editing, I think it should be ‘Subscriber Identity 
Information’, though, not ‘Subject’.  The BRs are a bit confused about what a 
Subject might be:

> Subject: The natural person, device, system, unit, or Legal Entity identified 
> in a Certificate as the Subject. The Subject is either the Subscriber or a 
> device under the control and operation of the Subscriber.

… so, in a certificate with CN=www.example.com/O=Example 
 Inc./C=US, is the Subject ‘Example Inc.’, or 
‘www.example.com’, and if the second, why is ‘www.example.com’ not Subject 
Identity Information, and if the first, then what is the Subject for 
‘CN=www.example.com’?



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] New validation method

[Geoff Keating via Public]

> On 24 Oct 2017, at 2:58 pm, Peter Bowen via Public  
> wrote:
> 
> As ballot 190 is complete and fully effective, it seems like a reasonable 
> time to start considering further validation method.  Amazon proposes the 
> following new method.  As far as I know, this does not overlap with any of 
> the existing methods.
> 
> 3.2.2.4.12 Registrar challenge validation
> Confirming the Applicant’s control over the request Domain Name by confirming 
> the presence of a Random Value or Request Token in a response from the Domain 
> Name Registrar or Registry received in response to a request containing an 
> Authorization Domain Name.

I like the concept, but can we be a bit more specific than just ‘in response to 
a request’?  For example, can we say ‘in response to a WHOIS request for the 
Authorization Domain Name’?

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 208 - dnQualifiers

[Geoff Keating via Public]

> On 22 Oct 2017, at 1:24 pm, Peter Bowen  wrote:
> 
>> Another workaround for individual cases is to identify the subscriber!  If 
>> you just supply the countryName field, that will do.  It can be determined 
>> and verified automatically in most cases.
> 
> If it would be agreeable to exclude countryName-only certificates from the 
> definition of certificates which "contain Subject Identity Information”, then 
> this seems like a reasonable workaround.  Otherwise section 7.1.6.1 directs 
> that these be designated OV certificates.

I don’t think it does… it says

> {joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) 
> certificate‐policies(1) baseline‐requirements(2) domain‐validated(1)} 
> (2.23.140.1.2.1), if the Certificate complies with these Requirements but 
> lacks Subject Identity Information that is verified in accordance with 
> Section 3.2.2.1 or Section 3.2.3.
> 
> If the Certificate asserts the policy identifier of 2.23.140.1.2.1, then it 
> MUST NOT include organizationName, givenName, surname, streetAddress, 
> localityName, stateOrProvinceName, or postalCode in the Subject field 

countryName is not in the list of things you can’t include, and it says 3.2.2.1 
not 3.2.2.3, so although countryName is ‘Subject Identity Information’ it is 
allowed in DV certificates if verified using 3.2.2.3(a)-3.2.2.3(c).  This makes 
sense because in the other cases you’re determining the countryName from the 
domain name or IP address.

In olden times some CAs would put countryName in all their DV certificates.  I 
suspect that was working around some other bug!



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 208 - dnQualifiers

[Geoff Keating via Public]

> On 22 Oct 2017, at 11:05 am, Peter Bowen  wrote:
> 
> The dnQualifier is designed to add “disambiguating information” to 
> Distinguished Names.  This ballot uses it for that purpose.  Notably I expect 
> CAs to use it to disambiguate certificates where there is no distinguished 
> name or where the CA has information that two certificates with identical 
> subjects were issued to different entities.

Isn’t it the case that every attribute adds “disambiguating information” to a 
name?  For example, countryName distinguishes between identically-named 
entities in different countries.  You have to read the entire description in 
order to find out how a particular attribute is used, and in this case, it’s to 
be used to distinguish between the same entity as seen by different systems.

> The issue that both Li-Chun and Geoff raise appears to be whether we should 
> use a different attribute type instead of dnQualifier.  The most obvious 
> suggestion would be to define a new attribute type, under an Object 
> Identifier arc that is managed by the Forum or a member.  However this 
> results in real-world compatibility issues.  There are numerous products 
> which error if a certificate DN contains attributes not on a whitelist.

I think you’ve undercut this ballot a bit by pointing out that:

> A bit of searching on “oid.map”, I did find the source, which is a PKIX 
> library from Certicom.  The part of oid.map that seems relevant is below.  I 
> note dnQualifier is not there, so maybe we should choose one of the 
> attributes below:

but if you still want to use dnQualifier, the obvious way to do it is to follow 
X.520 by having it be the same for a single CA, you could say something like

• Optional. Contents: This field distinguishes between the same entity 
in different Directory System Agents.  If present, the field MUST contain the 
commonName of one of the CA’s root or subordinate CA certificates (not 
necessarily one which issued this certificate).


I would suggest that there is a simpler workaround for individual cases, which 
is to give the host in question a shorter name (in addition to the long name) 
which can then be in the commonName field.  Most subscribers won’t encounter 
problems with an empty subject name, or will be able to update software to fix 
them, so this will not be something that needs to be done often.

Another workaround for individual cases is to identify the subscriber!  If you 
just supply the countryName field, that will do.  It can be determined and 
verified automatically in most cases.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 208 - dnQualifiers

[Geoff Keating via Public]

> On Oct 20, 2017, at 12:34 PM, Ryan Sleevi <sle...@google.com> wrote:
> 
> 
> 
> On Fri, Oct 20, 2017 at 3:14 PM, Geoff Keating <geo...@apple.com 
> <mailto:geo...@apple.com>> wrote:
> 
> 
>> On Oct 20, 2017, at 11:30 AM, Ryan Sleevi <sle...@google.com 
>> <mailto:sle...@google.com>> wrote:
>> 
>> 
>> 
>> On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating via Public 
>> <public@cabforum.org <mailto:public@cabforum.org>> wrote:
> 
>> - How this matches with the X.520 definition of dnQualifier, in particular 
>> the second sentence:
>> 
>> The DN Qualifier attribute type specifies disambiguating information to add 
>> to the relative distinguished name of an entry. It is intended to be used 
>> for entries held in multiple DSAs which would otherwise have the same name, 
>> and that its value be the same in a given DSA for all entries to which this 
>> information has been added.
>> 
>> This matches 1:1. Is there a concern that it doesn't match, or that more 
>> rules are necessary?
> 
> What I quoted above is X.520.  It doesn't seem to me to be describing the 
> same thing as the ballot.  In particular, normally you would consider a CA’s 
> issuing infrastructure to be one single DSA, which produces a contradiction 
> between the ballot text "The CA MAY set the dnQualifer value to the base64 
> encoding of the SHA1 hash of the subjectAlternativeName” and X.520’s text 
> “its value be the same in a given DSA”.
> 
>> - How this is actually intended to be used in the web PKI?
>> 
>> 
>> As raised on our most recent call, one notable thing is that this allows CAs 
>> to issue single certificates for domain names greater than 64 characters, at 
>> a DV level, while interoperably working with the Web PKI. This flows as 
>> follows:
>> 
>> - The X.509/RFC 5280 definition for commonName is limited to 64 characters.
>> - If you have a certificate with a domain name greater than 64 characters, 
>> you cannot place it in the common name of the subject.
>> - The common name of the subject may only contain domain names and IP 
>> addresses.
>> - All other specified fields of the Subject must be validated to OV level.
>> 
>> As a consequence, the only way with DV today to represent these certificates 
>> is with an empty sequence for the subject name and a critical 
>> subjectAltName, pursuant with RFC5280. You can see this at 
>> https://no-subject.badssl.com <https://no-subject.badssl.com/>
>> 
>> If you tried to load that on Apple iOS, it would load.
>> If you tried to load that on Apple macOS earlier than 10.10, it would load.
>> If you tried to load that on Apple macOS since 10.10, it will fail, as empty 
>> subjects are no longer supported.
> 
> It works for me in 10.11—so does that mean this ballot is no longer needed?
> 
> Just tested 10.12 and 10.13 and it's still failing - perhaps it was a point 
> release of 10.11?

*sigh* too many version numbers, all in the 10-13 range!  I meant macOS High 
Sierra 10.13, build 17A405.  That works for me when I use Safari to browse to 
https://no-subject.badssl.com <https://no-subject.badssl.com/>.

> Yes, it's still needed. While I highlighted Apple products specifically 
> (given the affiliation), the problem actually affects a number of clients - 
> hence why badssl has that site.
>  
>> This provides a way for a CA to ensure that a DV certificate with a domain 
>> name of more than 64 characters can be issued, by using the dnQualifier 
>> field (which is CA-controlled, as noted in the relevant X.520 text you 
>> cited) to serve as a disambiguator between certificates the CA has issued.
>> 
>> Does that help capture it?
> 
> I see the problem but I’m very hesitant to standardise something in CABforum 
> which contradicts X.520.
> 
> Have we really explored other alternatives?
> 
> I think we have. What would help you get that confidence?
>  
>  For example, truncate the commonName to 60 characters and append an ellipsis 
> in Unicode (“…”) so that it can’t be confused with a domain name.
> 
> That seems significantly more dangerous - for example, there's no guarantee 
> that the ellipsis avoids confusion, particularly in the conversion routine. 
> I'm also not sure I understand the concern regarding X.520 - which the Forum 
> has otherwise ignored in other specification of Subject naming attributes 
> when establishing rules.
> 
> Is the substance the concern about X.520 - that is, if there is a solution to 
> address your concern, then there's no need to get creative here?
> 
> For examp

Re: [cabfpub] Ballot 208 - dnQualifiers

[Geoff Keating via Public]

> On Oct 20, 2017, at 11:30 AM, Ryan Sleevi <sle...@google.com> wrote:
> 
> 
> 
> On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating via Public 
> <public@cabforum.org <mailto:public@cabforum.org>> wrote:

> - How this matches with the X.520 definition of dnQualifier, in particular 
> the second sentence:
> 
> The DN Qualifier attribute type specifies disambiguating information to add 
> to the relative distinguished name of an entry. It is intended to be used for 
> entries held in multiple DSAs which would otherwise have the same name, and 
> that its value be the same in a given DSA for all entries to which this 
> information has been added.
> 
> This matches 1:1. Is there a concern that it doesn't match, or that more 
> rules are necessary?

What I quoted above is X.520.  It doesn't seem to me to be describing the same 
thing as the ballot.  In particular, normally you would consider a CA’s issuing 
infrastructure to be one single DSA, which produces a contradiction between the 
ballot text "The CA MAY set the dnQualifer value to the base64 encoding of the 
SHA1 hash of the subjectAlternativeName” and X.520’s text “its value be the 
same in a given DSA”.

> - How this is actually intended to be used in the web PKI?
> 
> 
> As raised on our most recent call, one notable thing is that this allows CAs 
> to issue single certificates for domain names greater than 64 characters, at 
> a DV level, while interoperably working with the Web PKI. This flows as 
> follows:
> 
> - The X.509/RFC 5280 definition for commonName is limited to 64 characters.
> - If you have a certificate with a domain name greater than 64 characters, 
> you cannot place it in the common name of the subject.
> - The common name of the subject may only contain domain names and IP 
> addresses.
> - All other specified fields of the Subject must be validated to OV level.
> 
> As a consequence, the only way with DV today to represent these certificates 
> is with an empty sequence for the subject name and a critical subjectAltName, 
> pursuant with RFC5280. You can see this at https://no-subject.badssl.com 
> <https://no-subject.badssl.com/>
> 
> If you tried to load that on Apple iOS, it would load.
> If you tried to load that on Apple macOS earlier than 10.10, it would load.
> If you tried to load that on Apple macOS since 10.10, it will fail, as empty 
> subjects are no longer supported.

It works for me in 10.11—so does that mean this ballot is no longer needed?

> This provides a way for a CA to ensure that a DV certificate with a domain 
> name of more than 64 characters can be issued, by using the dnQualifier field 
> (which is CA-controlled, as noted in the relevant X.520 text you cited) to 
> serve as a disambiguator between certificates the CA has issued.
> 
> Does that help capture it?

I see the problem but I’m very hesitant to standardise something in CABforum 
which contradicts X.520.

Have we really explored other alternatives?  For example, truncate the 
commonName to 60 characters and append an ellipsis in Unicode (“…”) so that it 
can’t be confused with a domain name.

>  
>> On Oct 12, 2017, at 11:04 AM, Ben Wilson via Public <public@cabforum.org 
>> <mailto:public@cabforum.org>> wrote:
>> 
>> Ballot 208 - dnQualifiers
>> 
>> This ballot allows CAs to use dnQualifiers in certificates to partition 
>> groups of certificates into different sets and to allow non-identity 
>> information to be included in DV certificates. 
>> 
>> The following motion has been proposed by Peter Bowen of Amazon and endorsed 
>> by Ben Wilson of DigiCert and Ryan Sleevi of Google. 
>> 
>> -- MOTION BEGINS -- 
>> 
>> In the Baseline Requirements, REPLACE the definition of "Subject Identity 
>> Information" with: 
>> 
>> "Information that identifies the Certificate Subject. Subject Identity 
>> Information does not include [strikeout]a domain name listed in the 
>> subjectAltName extension or the Subject commonName field[/strikeout] 
>> [insert]dnQualifier attributes in Distinguished Names, commonName attributes 
>> in Distinguished Names, dNSName Subject Alternative Names, iPAddress Subject 
>> Alternative Names, or SRVName Subject Alternative Names[/insert]." 
>> 
>> In Section 7.1.4.2.2 Subject Distinguished Name Fields, re-letter "j" (Other 
>> Subject Attributes) as letter "k" and INSERT a new subsection j. that reads: 
>> 
>> j. Certificate Field: subject:dnQualifier 
>> 
>> Optional. Contents: This field is intended to be used when several 
>> certificates with the same subject can be partitioned into sets of related 
>> certi

Re: [cabfpub] Ballot 208 - dnQualifiers

[Geoff Keating via Public]

Did we actually have a discussion period on this?  I saw a pre-ballot but not 
the opening of a discussion period.

In any case, can someone explain:
- How this matches with the X.520 definition of dnQualifier, in particular the 
second sentence:

The DN Qualifier attribute type specifies disambiguating information to add to 
the relative distinguished name of an entry. It is intended to be used for 
entries held in multiple DSAs which would otherwise have the same name, and 
that its value be the same in a given DSA for all entries to which this 
information has been added.

- How this is actually intended to be used in the web PKI?

> On Oct 12, 2017, at 11:04 AM, Ben Wilson via Public  
> wrote:
> 
> Ballot 208 - dnQualifiers
> 
> This ballot allows CAs to use dnQualifiers in certificates to partition 
> groups of certificates into different sets and to allow non-identity 
> information to be included in DV certificates. 
> 
> The following motion has been proposed by Peter Bowen of Amazon and endorsed 
> by Ben Wilson of DigiCert and Ryan Sleevi of Google. 
> 
> -- MOTION BEGINS -- 
> 
> In the Baseline Requirements, REPLACE the definition of "Subject Identity 
> Information" with: 
> 
> "Information that identifies the Certificate Subject. Subject Identity 
> Information does not include [strikeout]a domain name listed in the 
> subjectAltName extension or the Subject commonName field[/strikeout] 
> [insert]dnQualifier attributes in Distinguished Names, commonName attributes 
> in Distinguished Names, dNSName Subject Alternative Names, iPAddress Subject 
> Alternative Names, or SRVName Subject Alternative Names[/insert]." 
> 
> In Section 7.1.4.2.2 Subject Distinguished Name Fields, re-letter "j" (Other 
> Subject Attributes) as letter "k" and INSERT a new subsection j. that reads: 
> 
> j. Certificate Field: subject:dnQualifier 
> 
> Optional. Contents: This field is intended to be used when several 
> certificates with the same subject can be partitioned into sets of related 
> certificates. Each related certificate set MAY have the same dnQualifier. The 
> CA may include a dnQualifier attribute with a zero length value to explicitly 
> indicate that the CA makes no assertion about relationship with other 
> certificates with the same subject. The CA MAY set the dnQualifer value to 
> the base64 encoding of the SHA1 hash of the subjectAlternativeName extnValue 
> if it wishes to indicate grouping of certificates by alternative name set. 
> -- MOTION ENDS -- 
> 
> The procedure for approval of this Final Maintenance Guideline ballot is as 
> follows (exact start and end times may be adjusted to comply with applicable 
> Bylaws and IPR Agreement): 
> 
> BALLOT 208 Status: Final Maintenance Guideline Start time (22:00 UTC) End 
> time (22:00 UTC) 
> 
> Discussion begins October 12, 2017 22:00 UTC and ends October 19, 2017 22:00 
> UTC (7 days) 
> 
> Vote for approval begins October 19, 2017 22:00 UTC and ends October 26, 2017 
> 22:00 UTC (7 days) 
> 
> If vote approves ballot: Review Period (Chair to send Review Notice) (30 
> days). If Exclusion Notice(s) filed, ballot approval is rescinded and PAG to 
> be created. If no Exclusion Notices filed, ballot becomes effective at end of 
> Review Period. Upon filing of Review Notice by Chair 30 days after filing of 
> Review Notice by Chair 
> 
> From Bylaw 2.3: If the Draft Guideline Ballot is proposing a Final 
> Maintenance Guideline, such ballot will include a redline or comparison 
> showing the set of changes from the Final Guideline section(s) intended to 
> become a Final Maintenance Guideline, and need not include a copy of the full 
> set of guidelines. Such redline or comparison shall be made against the Final 
> Guideline section(s) as they exist at the time a ballot is proposed, and need 
> not take into consideration other ballots that may be proposed subsequently, 
> except as provided in Bylaw Section 2.3(j). 
> 
> Votes must be cast by posting an on-list reply to this thread on the Public 
> list. A vote in favor of the motion must indicate a clear 'yes' in the 
> response. A vote against must indicate a clear 'no' in the response. A vote 
> to abstain must indicate a clear 'abstain' in the response. Unclear responses 
> will not be counted. The latest vote received from any representative of a 
> voting member before the close of the voting period will be counted. Voting 
> members are listed here: https://cabforum.org/members/ 
> 
> In order for the motion to be adopted, two thirds or more of the votes cast 
> by members in the CA category and greater than 50% of the votes cast by 
> members in the browser category must be in favor. Quorum is shown on 
> CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the required quorum 
> number must participate in the ballot for the ballot to be valid, either by 
> voting in favor, voting against, or abstaining. 
> 
>  
> 

[cabfpub] Blog post on Infineon key generation issue

[Geoff Keating via Public]

https://crocs.fi.muni.cz/public/papers/rsa_ccs17

“A newly discovered vulnerability in generation of RSA keys used by a software 
library adopted in cryptographic smartcards, security tokens and other secure 
hardware chips manufactured by Infineon Technologies AG ... Assess your keys 
now with the provided offline and online detection tools and contact your 
vendor if you are affected.”

It sounds like for CAs, the remediation is to implement the detection tool as a 
pre-check before issuing a certificate, and then start on the process of 
checking existing certificates for the flaw.___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA working group description

[Geoff Keating via Public]

I tried to write the CABForum WG charter so that it did not include changes to 
the CAA specification itself; these should indeed be handled at the IETF level. 
 This WG is about adoption of CAA in the Baseline Requirements.  Some topics we 
might cover are:

- Requirement for DNSSEC checking—for example, we might extend the current 
requirements so that CAs obtain and retain a record of the NSEC/NSEC3 record 
proving a subdomain does not use DNSSEC, even if they don’t actually check the 
crypto
- Error handling—for example, perhaps repeated failure to find a record should 
be treated as if the record is missing, rather than the current interpretation 
where we treat it as if the record exists and allows issuance, or we might just 
go to fail-closed
- Adoption of any new IETF RFCs, which may need to be phased in
- Adoption of any new IETF Errata

I don’t think any of these apply at the IETF level; I’m sure the IETF is not 
going to specify a ‘what if you only wanted a little bit of DNSSEC’ 
configuration, I think the IETF RFC should specify fail-closed because that’s 
the only fully secure approach, and the IETF can’t specify adoption of their 
standards in the Baseline Requirements.

> On 5 Oct 2017, at 11:09 am, Phillip via Public  wrote:
> 
> I can well imagine a possibility where the IETF WG might leave some parts of 
> the specification specified in less detail than would be desirable for 
> compliance purposes and thus make work in CABForum desirable. But lets cross 
> that bridge if we come to it.
>  
> What somewhat worries me is a situation in which I have ten CABForum members 
> tell me that they really want X in a CABForum group and then I report that 
> into the IETF WG and three people say they have other ideas and there being 3 
> of them and one of me, they represent the consensus. IETF process does allow 
> for liasons and there might be an argument for a CABForum/IETF liason. But 
> that does not seem like the right approach here.
>  
>  
>  
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Ryan Sleevi 
> via Public
> Sent: Thursday, October 5, 2017 1:52 PM
> To: Jacob Hoffman-Andrews ; CA/Browser Forum Public 
> Discussion List 
> Subject: Re: [cabfpub] CAA working group description
>  
> I agree with both Phillip and Jacob here. I think LAMPS is a great venue for 
> working out the technical issues of discussion - and identifying where policy 
> flexibility is needed or the challenges - and then bringing that as maybe one 
> or two more ballots into the Forum. I think the technical clarifications and 
> edge cases that we've seen discussed are totally within the realm of IETF's 
> goals of interoperability, so we should try to use that as much as possible :)
>  
> The extent of Forum ballots seems like it may be adopting one or two more 
> technical erratum (if interoperability issues arise and raised in IETF), and 
> then potentially exploring adopting the newer version being proposed in LAMPS 
> once completed.
>  
> On Thu, Oct 5, 2017 at 10:40 AM, Jacob Hoffman-Andrews via Public 
> > wrote:
>> With respect, I would suggest that there is already a CAA working group: the 
>> IETF LAMPS WG at https://datatracker.ietf.org/wg/lamps/charter/ 
>> . It has the advantage of 
>> being open for anyone to join and post, so CAs can more easily have 
>> conversations with Subscribers and Relying Parties. If half of the CAA 
>> conversation happens in LAMPS and half happens here, it will be harder for 
>> Subscribers and Relying Parties to fully participate.
>>  
>> I'd definitely encourage anyone in the CA/Browser Forum who is interested in 
>> CAA issues to join the LAMPS mailing list at 
>> https://www.ietf.org/mailman/listinfo/spasm 
>>  (confusingly, the mailing list 
>> is named SPASM, a holdover from an earlier name).
>>  
>> I think it's likely there will be another ballot or two in the CA/Browser 
>> Forum clarifying some of the language we use to incorporate CAA, but I think 
>> the amount of work is not enough to justify splitting out a second working 
>> group.
>> 
>> ___
>> Public mailing list
>> Public@cabforum.org 
>> https://cabforum.org/mailman/listinfo/public 
>> 
>  
> ___
> Public mailing list
> Public@cabforum.org 
> https://cabforum.org/mailman/listinfo/public 
> 


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] CAA working group description

[Geoff Keating via Public]

Ballot XXX - Formalization of validation working group


Reason 


As discussed at the CABforum meeting in Taipei, the Validation working group 
has proposed several ballots involving CAA.  It was thought that working group 
might now be somewhat busy with follow-ups from Ballot 190, that CAA is no 
longer obviously part of validation, and that perhaps a different group of 
people might be interested in CAA than in validation methods generally.

Geoffrey Keating of Apple Inc. made the following motion, which was endorsed by 
YYY and ZZZ


Motion begins

 
In accordance with Section 5.3 of the CA/B Forum Bylaws, the chartering of a 
new Working Group requires a ballot. This ballot charters the CAA Working 
Group.  The CAA Working Group’s charter will be as follows:

Scope

To consider and propose refinements and extensions to the Baseline Requirements 
related to checking for CAA records, RFC 6844, its errata, and its successors 
if any, taking into account implementation experience.

Deliverables

The Working Group shall produce:

- One or more ballots on the topics in its scope.
- Documents, as it sees fit, providing information to the Forum on 
implementation experience of CAA record checking.

Expiry

The Working Group shall expire once it determines that the deliverables have 
been completed, or on 2019-10-01, whichever happens first. 

Unless the working group has determined that its deliverables have been 
completed, the expiry date given above shall be automatically postponed by 1 
year on 2019-09-01 ("postponement date") and each anniversary of the 
postponement date thereafter unless three or more members separately or jointly 
request on the Public Mail List, within one month prior to a particular 
postponement date, that expiry of this Working Group not be postponed in that 
instance.


Motion Ends




smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] CAA look up failures and retry logic

[Geoff Keating via Public]

> On Oct 4, 2017, at 12:01 AM, Doug Beattie via Public  
> wrote:

> The BRs say if a lookup has been retried at least once that is permission to 
> issue. Does this mean doing
> -  a full CAA lookup, or 
> -  re-doing one failed CAA(X) look-up, or 
> -  redoing every CAA(X) lookup that failed in the course of doing a 
> full CAA validation?
>  
> If we follow the RFC processing logic and we encounter one failed lookup 
> (e.g., SERVFAIL on shop.example.com ), then we 
> retry and it fails again, then do we exit the CAA checking and issue because 
> the BRs say we may issue if we retry the lookup, which we just did?  Reading 
> the specs this seems to be permitted (we did “a” retry for a failed lookup), 
> common logic says no.

That’s an interesting point.  We could treat a (second) failure as meaning:
- Assume there is no CAA record here, continue with the algorithm, and maybe 
find a lower CAA record which denies issuance
- Assume there is a CAA record here which specifically allows issuance.

I believe the current wording is the second, not the first.  I think 
considering we’re just getting started with mandatory CAA, it’s OK to have this 
rule at the moment.  Switching to the first rule might be a way to tighten 
things once we’ve gotten some experience.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] DNSSEC validation for CAA record lookup failure

[Geoff Keating via Public]

> On 14 Sep 2017, at 12:11 pm, Wayne Thayer via Public <public@cabforum.org> 
> wrote:
> 
> Thanks Geoff. To be clear, does your proposed language require 
> ‘authentication of an NSEC RRset that proves that no DS RRset is present for 
> this zone’ in order to meet the new condition of the last item, or can an 
> unauthenticated query that returns no DS record be used to meet this 
> condition? If the former, then I wonder if the work to implement this is much 
> different than requiring full support for DNSSEC.

I don’t think we’re trying to require DNSSEC validation, so an unauthenticated 
query would be evidence.

I do draw your attention to RFC 6840, which clarifies some details, in 
particular section 4.4 explains the need to check that there’s a NS record 
served by the same servers that deny existence of a DS record.


> From: Public <public-boun...@cabforum.org> on behalf of Geoff Keating via 
> Public <public@cabforum.org>
> Reply-To: Geoff Keating <geo...@apple.com>, CA/Browser Forum Public 
> Discussion List <public@cabforum.org>
> Date: Thursday, September 14, 2017 at 10:03 AM
> To: CA/Browser Forum Public Discussion List <public@cabforum.org>
> Subject: [cabfpub] DNSSEC validation for CAA record lookup failure
>  
> At the moment the BRs say: 
>  
> CAs are permitted to treat a record lookup failure as permission to issue if:
> the failure is outside the CA's infrastructure;
> the lookup has been retried at least once; and
> the domain's zone does not have a DNSSEC validation chain to the ICANN root. 
> I suggest replacing the last item with “the record being looked up is 
> classified as ‘Insecure’ under RFC 4035 section 4.3, as amended.”
>  
> The most common case of this will be that the record being looked up is a CAA 
> record for, say, example.com <http://example.com/>; the .com servers have 
> been contacted successfully, producing authenticated NS records for 
> example.com <http://example.com/>, but the example.com <http://example.com/> 
> name servers cannot be contacted; and the .com servers have provided 
> authenticated denial of existence for a DS record for example.com 
> <http://example.com/>.  This is covered in RFC 4035 section 5.2, “If the 
> validator authenticates an NSEC RRset that proves that no DS RRset is present 
> for this zone, then there is no authentication path leading from the parent 
> to the child."
> ___
> Public mailing list
> Public@cabforum.org <mailto:Public@cabforum.org>
> https://cabforum.org/mailman/listinfo/public 
> <https://cabforum.org/mailman/listinfo/public>



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] DNSSEC validation for CAA record lookup failure

[Geoff Keating via Public]

> On Sep 14, 2017, at 2:37 PM, Peter Bowen <p...@amzn.com> wrote:
> 
> 
>> On Sep 14, 2017, at 10:02 AM, Geoff Keating via Public <public@cabforum.org> 
>> wrote:
>> 
>> At the moment the BRs say:
>> 
>> CAs are permitted to treat a record lookup failure as permission to issue if:
>> 
>> the failure is outside the CA's infrastructure;
>> 
>> the lookup has been retried at least once; and
>> 
>> the domain's zone does not have a DNSSEC validation chain to the ICANN root. 
>> 
>> I suggest replacing the last item with “the record being looked up is 
>> classified as ‘Insecure’ under RFC 4035 section 4.3, as amended.”
>> 
>> The most common case of this will be that the record being looked up is a 
>> CAA record for, say, example.com; the .com servers have been contacted 
>> successfully, producing authenticated NS records for example.com, but the 
>> example.com name servers cannot be contacted; and the .com servers have 
>> provided authenticated denial of existence for a DS record for example.com.  
>> This is covered in RFC 4035 section 5.2, “If the validator authenticates an 
>> NSEC RRset that proves that no DS RRset is present for this zone, then there 
>> is no authentication path leading from the parent to the child.”
> 
> Geoff,
> 
> This covers the “affirmatively insecure” case — that is a signed response 
> affirmatively indicates there are no DS records for a given name but there 
> are NS records for the same name.
> 
> However many of the cases are not as clear, especially in the face of NSEC3 
> with opt-out.  What if there is a DS record but the child zone returns an 
> answer that is covered in an opt-out gap?  

> What if the delegation without DS is covered in opt-out?  Are these both 
> affirmatively insecure?

If you happen to have that NSEC3 record, it is proof the lookup is insecure; 
but if there is a DS record, and you get a RRSIG for it, you can also do a 
secure lookup.

This sounds weird but it is still less weird than having both a NSSEC record 
that proves there is no DS record, and the signed DS record.

This can happen in normal operation if the NSEC/NSEC3 record is generated 
shortly before the DS record is added and hasn’t expired yet, for example.

> Also, take a look at 
> https://www.nlnetlabs.nl/bugs-script/show_bug.cgi?id=1439  There is 
> discussion there that highlights another challenge: what happens in error 
> cases.  How should CAs handle a case where they are trying to get data for 
> beta.shop.example.com, example.com has a DS record in the com zone, but there 
> are no DNSKEY records for example.com in the example.com zone?  We don’t know 
> if shop.example.com is insecure or secure.

At this point, you’ll have queried the .com servers for the CAA record for 
beta.shop.example.com, and been given a referral to the example.com servers 
containing NS and DS records, and not a NSEC or NSEC3 response proving there is 
no DS record. Then you try to query the example.com nameservers, for either the 
CAA or DNSKEY, and it fails.

The exemption does not apply because you can’t prove that the lookup that 
failed is of a record classified as ‘insecure’.___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

[cabfpub] DNSSEC validation for CAA record lookup failure

[Geoff Keating via Public]

At the moment the BRs say:

CAs are permitted to treat a record lookup failure as permission to issue if:

the failure is outside the CA's infrastructure;

the lookup has been retried at least once; and

the domain's zone does not have a DNSSEC validation chain to the ICANN root. 

I suggest replacing the last item with “the record being looked up is 
classified as ‘Insecure’ under RFC 4035 section 4.3, as amended.”

The most common case of this will be that the record being looked up is a CAA 
record for, say, example.com ; the .com servers have been 
contacted successfully, producing authenticated NS records for example.com 
, but the example.com  name servers 
cannot be contacted; and the .com servers have provided authenticated denial of 
existence for a DS record for example.com .  This is 
covered in RFC 4035 section 5.2, “If the validator authenticates an NSEC RRset 
that proves that no DS RRset is present for this zone, then there is no 
authentication path leading from the parent to the child."

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] EV 11.2.1 Private Organization registration number or date

[Geoff Keating via Public]

> On 31 Aug 2017, at 2:42 pm, Kirk Hall via Public  wrote:
> 
> Geoff – clearly this applicant will now be denied, but I have to disagree 
> with one of your underlying assumptions below - “there is no way to uniquely 
> identify the entity”.  Rich Smith of Comodo indicated that the applicant’s 
> corporate registration had been confirmed with the government authority – 
> perhaps based on address or some other identifying factor.  Again, when we 
> drafted the EVGL (I think I drafted this particular section), we assumed 
> there would be a registration number or date of registration in all records 
> (we were wrong), but even without that, a CA would have the ability to 
> confirm proper corporate registration tied to the applicant’s unique identity 
> so that identity would be confirmed.

Even assuming that there isn’t the possibility of two simultaneous 
registrations of different entities with the same name (hopefully the 
government authority prevents this), one question is whether, in future, this 
entity could dissolve, and a new distinct entity could be created with the same 
name at the same address.  I don’t know what kind of entity we’re talking 
about, so I don’t know how easy this would be.  In some cases, for example 
partnerships in the US, this happens routinely and frequently.

> I think we should amend EVGL 11.2.1 (1)(c) to allow some other method for 
> recording the confirmation of proper corporate registration.  Since Rich 
> knows the facts if this case, I’ll leave it to him to come up with any 
> amending language.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] EV 11.2.1 Private Organization registration number or date

[Geoff Keating via Public]

> On 31 Aug 2017, at 1:21 pm, Kirk Hall via Public  wrote:
> 
> There is a well-established legal doctrine of “Impossibility”, which excuses 
> performance of a requirement under certain limited conditions.
>  
> https://en.wikipedia.org/wiki/Impossibility 
> 
>  
> In limited cases, it seems that doctrine could apply to the BRs. 
>  
> Here, we assumed every jurisdiction would provide a registration number or 
> date when passing the EVGL rule, but we were incorrect.  It seems that 
> substitute performance by a CA would fulfill the spirit and purpose of the 
> EVGL rule (where absolute compliance is impossible), which doesn’t bother me. 
>  In the meantime, we should also amend the EVGL to allow for this case (where 
> there is no registration number or date).

In general, for EV certificate issuance, I believe that if a certificate can’t 
be issued under the EV criteria, it must not be issued.  It’s expected that 
some organizations or entities will not be able to get an EV certificate for 
one reason or another, and “there is no way to uniquely identify the entity” is 
definitely one of those reasons.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] EV 11.2.1 Private Organization registration number or date

[Geoff Keating via Public]

> On 31 Aug 2017, at 8:29 am, Rich Smith via Public  wrote:
> 
> EVG 11.2.1 (1)(c) states:
> (C) Registration Number: Obtain the specific Registration Number assigned to 
> the Applicant by the Incorporating or Registration Agency in the Applicant's 
> Jurisdiction of Incorporation or Registration. Where the Incorporating or 
> Registration Agency does not assign a Registration Number, the CA SHALL 
> obtain the Applicant's date of Incorporation or Registration.
>  
> What if the Registration Agency simply does not publish, and will not provide 
> either registration number or date?  In the case I’m looking at they have 
> legal name, registered address and phone number.  There is no registration 
> number nor date published and they will not provide either one even when our 
> agents call in and ask for the information.
>  
> If the only answer at this time is, “Then we can’t issue an EV cert,” which 
> is the direction I’m leaning, then I’d like to discuss/propose changing “CA 
> SHALL” in the above to “CA SHOULD”.
> 
> Feedback would be much appreciated, especially from those who might be 
> willing to endorse such a ballot or those who might be strongly opposed to 
> such a ballot.  If anyone has a sound argument that we actually can issue an 
> EV under the current wording, I’d love to hear that as well.

The last sentence in (c) above does not contain the words “from the 
Incorporating or Registration Agency”, so is there any other way you can obtain 
the date of registration?


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Random value reuse

[Geoff Keating via Public]

You can skywrite it above their headquarters, I think, unless the method you’re 
using specifies otherwise!

> On 9 Aug 2017, at 2:45 pm, Jeremy Rowley  wrote:
> 
> It raises a lot of questions though.  Can I email the Random Value to a 
> reseller who forwards it on to the end entity?  Can I display it on a website 
> without them logging in?  Right now, no security or controls is built on 
> delivery of Random Value. 
> 
> -Original Message-
> From: Ben Wilson 
> Sent: Wednesday, August 9, 2017 3:33 PM
> To: geo...@apple.com
> Cc: CA/Browser Forum Public Discussion List ; Gervase 
> Markham ; Jeremy Rowley ; Rich 
> Smith ; Peter Bowen 
> Subject: RE: [cabfpub] Random value reuse
> 
> I suppose you're right, since the definition of "Random Value" is "A value 
> specified by a CA to the Applicant that exhibits at least 112 bits of 
> entropy."
> 
> 
> -Original Message-
> From: geo...@apple.com [mailto:geo...@apple.com] 
> Sent: Wednesday, August 9, 2017 3:30 PM
> To: Ben Wilson 
> Cc: CA/Browser Forum Public Discussion List ; Gervase 
> Markham ; Jeremy Rowley ; Rich 
> Smith ; Peter Bowen 
> Subject: Re: [cabfpub] Random value reuse
> 
> 
>> On 9 Aug 2017, at 2:24 pm, Ben Wilson  wrote:
>> 
>> Agreed.  And each method should stand on its own without cross-referencing 
>> among methods (otherwise tracking the particular method used will be too 
>> complicated).  So I'm OK without cross-referencing methods.
>> 
>> But are we clear enough?  For example, the currently proposed method 10 
>> could probably benefit from better language on how the applicant obtains the 
>> random value.  Currently it only says, "Confirming the Applicant's control 
>> over the FQDN by confirming the presence of a Random Value within a 
>> Certificate on the Authorization Domain Name which is accessible by the CA 
>> via TLS over an Authorized Port."  The other methods seem to specify the 
>> process more thoroughly.
> 
> I think it doesn’t matter, in this case, how the Random Value gets to the 
> Applicant—we don’t want to overspecify things like this, because that limits 
> the ability of CAs to innovate.
> 
>> 
>> -Original Message-
>> From: geo...@apple.com [mailto:geo...@apple.com] 
>> Sent: Wednesday, August 9, 2017 3:11 PM
>> To: Ben Wilson ; CA/Browser Forum Public Discussion 
>> List 
>> Cc: Gervase Markham ; Jeremy Rowley 
>> ; Rich Smith ; Peter 
>> Bowen 
>> Subject: Re: [cabfpub] Random value reuse
>> 
>> I think that’s where the ‘single communication’ rule really helps.  Then 
>> this is taken care of by the descriptions of the methods: if you have to 
>> send the random value to a particular place, then obviously that can’t be 
>> combined with a random value sent some other way; if you have to put it in a 
>> particular place, then it doesn’t matter how it was sent…
>> 
>>> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public  
>>> wrote:
>>> 
>>> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
>>> which random value methods can be used in combination with others?  It 
>>> seems that a random value could be provided to the domain contact / admin 
>>> under methods 2, 3 (if you wanted) or 4 and then used within 30 days for 
>>> methods 2, 4, 6, 7 and 10,  but not vice versa.
>>> 
>>> -Original Message-
>>> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase 
>>> Markham via Public
>>> Sent: Monday, July 31, 2017 9:02 AM
>>> To: Jeremy Rowley ; CA/Browser Forum Public 
>>> Discussion List ; Rich Smith 
>>> ; 'Peter Bowen' 
>>> Subject: Re: [cabfpub] Random value reuse
>>> 
>>> On 28/07/17 14:53, Jeremy Rowley via Public wrote:
 I think the random value should be tied to a single communication 
 without reuse.  For example, a single email sent to the constructed 
 emails, a single API call, a single phone call, etc.  The random value 
 shouldn’t be tied to a method, but should be tied to a specific 
 communication from the CA that is tied to a request. By getting rid of 
 the reuse language, we can simplify the process and eliminate the risk 
 associated with reuse.
>>> 
>>> Right. New random values are cheap :-)
>>> 
>>> Gerv
>>> ___
>>> Public mailing list
>>> Public@cabforum.org
>>> https://cabforum.org/mailman/listinfo/public
>>> ___
>>> Public mailing list
>>> Public@cabforum.org
>>> 

Re: [cabfpub] Random value reuse

[Geoff Keating via Public]

> On 9 Aug 2017, at 2:24 pm, Ben Wilson  wrote:
> 
> Agreed.  And each method should stand on its own without cross-referencing 
> among methods (otherwise tracking the particular method used will be too 
> complicated).  So I'm OK without cross-referencing methods.
> 
> But are we clear enough?  For example, the currently proposed method 10 could 
> probably benefit from better language on how the applicant obtains the random 
> value.  Currently it only says, "Confirming the Applicant's control over the 
> FQDN by confirming the presence of a Random Value within a Certificate on the 
> Authorization Domain Name which is accessible by the CA via TLS over an 
> Authorized Port."  The other methods seem to specify the process more 
> thoroughly.

I think it doesn’t matter, in this case, how the Random Value gets to the 
Applicant—we don’t want to overspecify things like this, because that limits 
the ability of CAs to innovate.

> 
> -Original Message-
> From: geo...@apple.com [mailto:geo...@apple.com] 
> Sent: Wednesday, August 9, 2017 3:11 PM
> To: Ben Wilson ; CA/Browser Forum Public Discussion 
> List 
> Cc: Gervase Markham ; Jeremy Rowley 
> ; Rich Smith ; Peter 
> Bowen 
> Subject: Re: [cabfpub] Random value reuse
> 
> I think that’s where the ‘single communication’ rule really helps.  Then this 
> is taken care of by the descriptions of the methods: if you have to send the 
> random value to a particular place, then obviously that can’t be combined 
> with a random value sent some other way; if you have to put it in a 
> particular place, then it doesn’t matter how it was sent…
> 
>> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public  wrote:
>> 
>> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
>> which random value methods can be used in combination with others?  It seems 
>> that a random value could be provided to the domain contact / admin under 
>> methods 2, 3 (if you wanted) or 4 and then used within 30 days for methods 
>> 2, 4, 6, 7 and 10,  but not vice versa.
>> 
>> -Original Message-
>> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase 
>> Markham via Public
>> Sent: Monday, July 31, 2017 9:02 AM
>> To: Jeremy Rowley ; CA/Browser Forum Public 
>> Discussion List ; Rich Smith 
>> ; 'Peter Bowen' 
>> Subject: Re: [cabfpub] Random value reuse
>> 
>> On 28/07/17 14:53, Jeremy Rowley via Public wrote:
>>> I think the random value should be tied to a single communication 
>>> without reuse.  For example, a single email sent to the constructed 
>>> emails, a single API call, a single phone call, etc.  The random value 
>>> shouldn’t be tied to a method, but should be tied to a specific 
>>> communication from the CA that is tied to a request. By getting rid of 
>>> the reuse language, we can simplify the process and eliminate the risk 
>>> associated with reuse.
>> 
>> Right. New random values are cheap :-)
>> 
>> Gerv
>> ___
>> Public mailing list
>> Public@cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>> ___
>> Public mailing list
>> Public@cabforum.org
>> https://cabforum.org/mailman/listinfo/public
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Random value reuse

[Geoff Keating via Public]

I think that’s where the ‘single communication’ rule really helps.  Then this 
is taken care of by the descriptions of the methods: if you have to send the 
random value to a particular place, then obviously that can’t be combined with 
a random value sent some other way; if you have to put it in a particular 
place, then it doesn’t matter how it was sent…

> On 9 Aug 2017, at 1:54 pm, Ben Wilson via Public  wrote:
> 
> Putting the  issue of "reuse" aside, do we need to clarify this issue of 
> which random value methods can be used in combination with others?  It seems 
> that a random value could be provided to the domain contact / admin under 
> methods 2, 3 (if you wanted) or 4 and then used within 30 days for methods 2, 
> 4, 6, 7 and 10,  but not vice versa.
> 
> -Original Message-
> From: Public [mailto:public-boun...@cabforum.org] On Behalf Of Gervase 
> Markham via Public
> Sent: Monday, July 31, 2017 9:02 AM
> To: Jeremy Rowley ; CA/Browser Forum Public 
> Discussion List ; Rich Smith ; 
> 'Peter Bowen' 
> Subject: Re: [cabfpub] Random value reuse
> 
> On 28/07/17 14:53, Jeremy Rowley via Public wrote:
>> I think the random value should be tied to a single communication 
>> without reuse.  For example, a single email sent to the constructed 
>> emails, a single API call, a single phone call, etc.  The random value 
>> shouldn’t be tied to a method, but should be tied to a specific 
>> communication from the CA that is tied to a request. By getting rid of 
>> the reuse language, we can simplify the process and eliminate the risk 
>> associated with reuse.
> 
> Right. New random values are cheap :-)
> 
> Gerv
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] notBefore dates for certificates

[Geoff Keating via Public]

> On 1 Aug 2017, at 6:13 pm, Peter Bowen via Public  wrote:
> 
> We’ve had an interesting situation come up that isn’t clearly covered in the 
> BRs.
…
> So I have two questions:
> 1) Does anyone think setting a notBefore well before the issuance dates a 
> problem, as long as the certificate includes a timestamp that represents the 
> issuance date and the CA previously issued a certificate for the same domain 
> name(s) to the same applicant that has a validity period that spans from the 
> notBefore to issuance date?

I can’t immediately think of any reason not to allow this, but if you do this, 
please create a precertificate, upload it to CT, and put a SCT in the 
certificate as an indicator of the the actual time of issuance.

(I think it’s a good general rule that the more weird is the thing you’re 
doing, the more transparent you want to be about it.)

> 2) What is the latest acceptable notAfter date?  39 months (or 825 days in 
> the future) from the notBefore date or from the issuance date?

From the issuance date—in the BRs, the ‘Validity Period’ runs from issuance to 
expiry.  In fact I can’t find anything in the BRs about when the notBefore 
timestamp should be.

What people will actually check is the time between the SCT and the certificate 
expiry.  Make sure that’s less than 39 months/825 days.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

[Geoff Keating via Public]

My understanding is that the punycode issue is not altered by this ballot, 
because the current definitions state:
Domain Name: The label assigned to a node in the Domain Name System.

and in the DNS, the label assigned to a node with an internationalised domain 
name is encoded in punycode.  So it is not allowed to produce certificates with 
UTF-encoded IDNs today.


I think that if GDCA is serious about this concern, they should propose a 
ballot which removes the restriction that commonName must match one of the 
subjectAltNames.  I don’t know if the world is ready for such a ballot yet, but 
I think the resulting discussion would be beneficial.  Perhaps the ballot could 
propose some additional restriction(s), such as that the commonName must 
contain a space, or a character higher than 0x00FF in unicode, or must not 
contain a period, so that the commonName couldn’t be mistaken for a domain name.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

[Geoff Keating via Public]

> On Jul 25, 2017, at 1:01 PM, Peter Bowen  wrote:
> 
> 
>>> On Jul 25, 2017, at 12:25 PM, Geoff Keating  wrote:
>>> 
>>> 
>>> On 25 Jul 2017, at 12:01 pm, Peter Bowen via Public  
>>> wrote:
>>> 
>>> Erwann,
>>> 
>>> Thank you for your detailed feedback and I appreciate you providing context 
>>> for your vote.
>>> 
>>> With regards to reserved IP addresses, the definition in the current BRs 
>>> allows a CA to deliver a certificate for 192.0.0.9.  They also allow a CA 
>>> to deliver a certificate for 192.168.1.1.  This is because the current 
>>> language (which has been in the BRs since at least V1) says “Reserved IP 
>>> Address” is only defined by the whole /8 being reserved.  This means only 
>>> 0/8, 10/8, 127/8 and 224/3 are currently Reserved IP v4 addresses.  While I 
>>> agree we may be able to further restrict issuance, this ballot covers the 
>>> common cases.
>> 
>> That’s not what the language says… the new language says
> 
> By “current” language I meant the language in BR 1.4.9, which says:
> 
> Reserved IP Address: An IPv4 or IPv6 address that the IANA has marked as 
> reserved: 
> http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml
> http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml
> 
> This is the language that only reserves /8 or larger ranges for IP v4.

I don’t see the part of that which is limited to large ranges?  The definition 
says ‘address’, not ‘address range’ implying each address is considered 
individually.  The URLs no longer resolve.

> F. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition 
> for "Reserved IP Address" with the following: An IPv4 or IPv6 address 
> that the IANA has "False" for Globally Reachable in either of the IANA 
> Special-Purpose IP Address Registries: 
> 
> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
>  or 
> 
> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
> 
>> 
>> and the first of those links has 192.168.0.0/16 marked as ‘false’ for 
>> globally reachable.  Now, it’s true that 192.0.0.9/32 is marked ‘true’ for 
>> globally reachable, but I don’t think that anyone should be able to 
>> authenticate themselves as controlling that address, so no CA would issue a 
>> certificate containing that address.
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 202 - Underscore and Wildcard Characters

[Geoff Keating via Public]

> On 25 Jul 2017, at 12:01 pm, Peter Bowen via Public  
> wrote:
> 
> Erwann,
> 
> Thank you for your detailed feedback and I appreciate you providing context 
> for your vote.
> 
> With regards to reserved IP addresses, the definition in the current BRs 
> allows a CA to deliver a certificate for 192.0.0.9.  They also allow a CA to 
> deliver a certificate for 192.168.1.1.  This is because the current language 
> (which has been in the BRs since at least V1) says “Reserved IP Address” is 
> only defined by the whole /8 being reserved.  This means only 0/8, 10/8, 
> 127/8 and 224/3 are currently Reserved IP v4 addresses.  While I agree we may 
> be able to further restrict issuance, this ballot covers the common cases.

That’s not what the language says… the new language says

>>> F. In Section 1.6.1 of the Baseline Requirements, REPLACE the definition 
>>> for "Reserved IP Address" with the following: An IPv4 or IPv6 address that 
>>> the IANA has "False" for Globally Reachable in either of the IANA 
>>> Special-Purpose IP Address Registries: 
>>> 
>>> https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
>>>  
>>> 
>>>  or 
>>> 
>>> https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
>>>  
>>> 
and the first of those links has 192.168.0.0/16 marked as ‘false’ for globally 
reachable.  Now, it’s true that 192.0.0.9/32 is marked ‘true’ for globally 
reachable, but I don’t think that anyone should be able to authenticate 
themselves as controlling that address, so no CA would issue a certificate 
containing that address.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Revocation ballot

[Geoff Keating via Public]

> On Jul 18, 2017, at 12:03 AM, Jeremy Rowley  
> wrote:
> 
> Hi Geoff, 
> 
> I'm not sure I understand your post.  Are you commenting on the proposed 
> changes or what's currently in the document?  From what I read, you'd like to 
> see the 24 hour rule remain except in the limited circumstances described 
> below? 

The proposed changes, at least one version of them.  Yes, keep the 24 hour rule 
but for these.

> 
> 
> I do think these timeframes are a bit loose.  I wouldn’t like to see a CA 
> explaining “well, we tried to contact the customer, and they haven’t replied, 
> so we’re waiting the full fourteen business days” in response to being handed 
> a copy of the private key.  Or if the actual domain owner appears and says 
> “hey, you issued a certificate for my domain and I didn’t authorize it” and 
> the CA then takes weeks to revoke.
> [JR] Both of these events require revocation within 1 business day

With the proposed changes, though, these are all Problem Reports that trigger 
investigations, and can take many business days to resolve.

> However, I don’t think there’s so much of a problem in some specific cases:
> - For item 1, the customer may voluntarily request a revocation at some time 
> in the future.  The CA must still act on it within 24 hours of the requested 
> time.  If the revocation is requested because of key compromise or change of 
> information (and so is not voluntary, it is mandated by the Subscriber 
> agreement), the following items control.
> [JR] I don't see how this is allowed. The CA is required to revoke within 24 
> hours under the current requirement and 1 business day under my proposal if 
> the subscriber requests revocation. However, I like this exception as the 
> subscriber can plan a specific time and date for revocation.  
> 
> - If the private key has been compromised, and the customer is contacted 
> within 2 business days and accepts the risk, the subscriber may delay 
> revocation for up to 1 week from the time the CA is first notified.  (This is 
> item 3.)
> [JR] The current timeline is 24 hours. I proposed 1 business day.  Are you 
> saying that 2 business days is acceptable to Apple with a 1 week delay in 
> revocation from the date of notice?

The times overlap, so from the moment of notice, you get 24 hours for a 
preliminary report, 2 business days to contact the subscriber, 3 business days 
to complete the investigation, and 1 week maximum before the certificate is 
revoked. If you can’t contact the subscriber, you get 24 hours from the end of 
the investigation to revoke, or a week, whichever is less.

> 
> - If there is a material change to the certificate information other than the 
> DNS name, such as the address, I think the revocation can be delayed for up 
> to 10 business days from the date the information changed, to allow a smooth 
> changeover, if the customer requests it.  This only applies if the previous 
> information was valid but has changed.  (This is item 8 or 10.)
> [JR] Thanks. 10 business days is fine with me as well.
> 
> I think you want to word these like this.  Otherwise you can end up in a 
> scenario where someone reports a key compromise to the customer, the customer 
> is required by the Subscriber Agreement to report it immediately to the CA 
> and request revocation, which is not a Problem Report, and it must be revoked 
> within 24 hours; but if it had been reported to the CA, it could have taken 
> up to 2 weeks.  And of course if the reporter sees it’s not revoked fast 
> enough, the reporter can then go to the CA and say the subscriber is not 
> following their Subscriber Agreement, which might have consequences far 
> beyond one certificate.
> [JR] Good point. 
> 
> For all other items, I don’t see why 24 hours is unreasonable for the actual 
> revocation.  I think setting a deadline on any investigations caused by a 
> problem report is also a good idea, and think 24 hours for initial response 
> then 3 business days for final action is OK.
> [JR] There are others.
> a) Requiring revocation for non-payment seems counter-productive to the goal 
> of making revocation a technical control, not a business control.  The CA is 
> forced to revoke within 24 hours if payment is delayed by a couple days 
> because of a violation of the subscriber agreement (#6).  

I think this is an agreement wording problem. A CA can word the agreement so 
that a delay in payment does not count as a violation.

> b) If I put in my CPS that I will revoke 14 days after receiving notice of a 
> trademark being awarded to a third party (but not the domain name), then you 
> could argue that the CA actually only has 24 hours because revocation is 
> required by the CPS (the timing in the CPS is irrelevant).  

You can word the CPS to avoid this.

> c) Similarly, if technical content presents an unacceptable risk, does the 
> timeline set for deprecation really control or does the 24 hour rule in this 

Re: [cabfpub] Problems with Ballot 202

[Geoff Keating via Public]

I was wondering about that.  We seem to be trying to redefine the DNS without 
referencing its foundational documents.  How about:

Domain Label: A label of a domain name, as defined in RFC 1034.
Domain Name: A string which is a ‘domain name’ as defined in RFC 1034 with 
labels separated by dots, or a Wildcard Domain Name.
Domain Namespace (of a domain): All domains which are subdomains of the 
referenced domain, as described in RFC 1034.
Fully Qualified Domain Name: A domain name interpreted relative to the root.  
The Fully Qualified Domain Names used in this document do not end with a period.
Wildcard Domain Name: The string ‘*.’ followed by a ‘domain name’ with labels 
separated by dots as defined in RFC 1034.

> On 17 Jul 2017, at 3:28 pm, Kirk Hall via Public  wrote:
> 
> Here are the difficulties I’m having understanding the new (very complex) 
> Ballot 202 definitions shown below.  I can’t imagine explaining this to our 
> engineering and vetting teams, and I think people will make mistakes.  
> Assuming these definitions parse out, at a bare minimum we should give easy 
> examples for each definition.  These are arranged in a logical order, not 
> alphabetically.
>  
> Also – we won’t really know if these definitions are good and useful unless 
> we compare them to the new text of BR 3.2.2.4, which defines how we are to do 
> validation.  Last week when we pulled back Ballot 190 it was to allow Peter 
> time to tune up the definition of Authorized Domain Name in Ballot 190 the 
> context of BR 3.2.2.4 (so we could remove the Notes that had been added to 
> Ballot 190), but to my surprise, the new definitions have shown up in Ballot 
> 202 instead – I think that’s a mistake.   
>  
> As recently as July 4, Ben said this Ballot 202 would cover the following 
> four subjects: (1) adds dnQualifier as an allowed attribute for all 
> certificate types (including DV), (2) adds ASN.1 info on the EV jurisdiction 
> attribute types, (3) adds language to the EV guidelines to clarify that CAs 
> may limit their aggregate liabilities, (4) allows underscores in domain names 
> and clarifies what can go in common names.  Why did the authors decide to 
> include changes to crucial definitions applicable to domain validation at the 
> same time, but not allow discussion in a pre-ballot?
> 
> At this point, Entrust is inclined to vote no – not because we necessarily 
> oppose the ballot’s aims, but because there are some questions and no time to 
> resolve them before voting starts.
>  
> Here are our concerns about the new definitions.  Again, it would be nice to 
> have more time to discuss, and not start voting on Wednesday.
>  
> Domain Label: An individual component of a Domain Name.  
>  
> [What does this mean – “component”?  Is a period a Domain Label?  A couple of 
> letters?  This seems circular with the Domain Name definition below.  Did you 
> mean “node” and not “component”?  At a minimum, give examples – “In 
> mail.example.com , the components are “mail”, 
> “example”, and “com”.  The period “.” is not a component, nor are characters 
> that are less than a full node such as “exa”.]
>  
> Domain Name:  A set of one or more Domain Labels, each separated by a single 
> full stop character (".").  Fully-Qualified Domain Names and Wildcard Domain 
> Names are Domain Names. 
>  
> [Again, somewhat circular – Domain Label says it’s a component of a Domain 
> Name, and Domain Name says it’s made up of Domain Labels… never fully 
> defined. 
>  
> Also, saying that FQDNs and Wildcard DNs are DNs might work, but need to 
> study the rest of the text. 
>  
> Also, this definition does not require a domain name to end in a gTLD or 
> ccTLD, so server1.mail qualifies as a Domain Name?  Might cause trouble with 
> other definitions.]
>  
> Domain Namespace:  The set of all possible Domain Names that are subordinate 
> to a single node in the Domain Name System.
>  
> [Unclear – “subordinate to a single node in the Domain Name System”.  So for 
> server1.mail.example.com , is “com” part of 
> the Domain Namespace, or only server1.mail.example?  Also, you say in the 
> definition of Domain Name that an FQDN is a Domain Name, so under the 
> Definition of Domain Namespace, is the entire FQDN (including .com) meant to 
> be subordinate to a single node in the Domain Name System?  Would that 
> require server1.mail.example.com. com 
> , with the second “.com” being the 
> single node?
>  
> In the example server1.mail.example.com , 
> “server1” and “mail” are subordinate to “example”, so does that mean 
> “server1.mail” is a Domain Namespace that is subordinate to the node 
> “example”?
>  
> Also – we never use Domain Namespace in the rest of the definitions.  Where 
> is it used, and does this definition make sense there?]
>  

Re: [cabfpub] What is 'misuse'?

[Geoff Keating via Public]

> On 17 Jul 2017, at 12:48 pm, Rich Smith via Public  
> wrote:
> 
> Ryan,
> First of all, thank you for taking the time to post a reply.  I did the 
> Mozilla discussion when it was happening, and I've reviewed it again.  I may 
> be missing something, but the gist of it seems to be that misuse is pretty 
> much whatever the particular CA in question decides it is, and Mozilla seems 
> to have punted by changing the wording to eliminate the word 'misuse' from 
> their policy.  Not particularly helpful unless "whatever the CA decides it 
> is," is in fact the accepted definition, which does seem to be the end result 
> of Mozilla's wording as well.  It's not  particularly useful, as a matter of 
> clarity of the BRs, to need to refer to some discussion that took place eons 
> ago on another forum which only affects one browser's program, not the BRs 
> themselves.  And while I don't doubt your recollection that the discussion 
> around Ballot 161 may have touched upon the confusion around 'misuse' the 
> ballot itself did not address it in any way.
> 
> It seems that our options are:
> 1) Accept the de facto definition of misuse = whatever the particular CA 
> decides it means
> If that's the case then it seems pointless to have it in the BRs at all and 
> we should draft a ballot to remove it, OR;

One case that I think ‘misuse' does cover is the case where a Key Compromise 
has not occurred but there have been other circumstances where the key has been 
accessed.  For example, the situation where the key of a subordinate CA is 
stored in a HSM and has not been exported but it is discovered that an attacker 
has signed some unknown data with that key.

However this would be clearer if the relevant line said that the private key 
was misused, not the certificate.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Fixup ballot for CAA

[Geoff Keating via Public]

Perhaps we should have a general rule that all RFC references mean a reference 
to the RFC plus all approved errata?

> On 5 Jun 2017, at 9:04 am, Phillip via Public  wrote:
> 
> Implementation of CAA turned up an issue to do with the recursive treatment 
> of pointer records. An errata has been proposed to fix the specification to 
> achieve the processing agreed to be desirable:
> 
> https://www.rfc-editor.org/errata_search.php?eid=4992
> 
> I would like to propose a motion to fix this issue so that implementations 
> use the search specified in the errata rather than the original text.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Preballot - Revised Ballot 190

[Geoff Keating via Public]

I feel like we’re going around in circles here.

The question you’re asking is wrong.  It is not a valid question.  It is a 
question that relies on false premises.

At the time that the baseline requirements apply, that is the moment of 
certificate issuance, it is not possible that you can be considering the 
correctness of a validation without having an Applicant and a request.  If 
there isn’t an Applicant, or there isn’t a request, the certificate is already 
misissued and so it does not matter what validations were done.

The baseline requirements describe the validations that must have been done.  
They do this in the context of the Applicant and request that applied to this 
specific certificate issuance.  These validations must have been done (that is, 
they must be in the past) at the time of issuance.  Before, when the 
validations were actually done, it might not have been possible to know which 
certificate(s) they were being done for, but that is irrelevant to the BRs.

This is made exceptionally clear in section 3.2.2.4,

> The CA SHALL confirm that, as of the date the Certificate issues, either the 
> CA or a Delegated Third Party has validated each Fully‐Qualified Domain Name 
> (FQDN) listed in the Certificate using at least one of the methods listed 
> below.

Reading this carefully, you see that the CA’s responsibility for validation 
occurs at "the date the Certificate issues”. Then in section 4.1.2, you have 
also the very clear sentence

> Prior to the issuance of a Certificate, the CA SHALL obtain from the 
> Applicant a certificate request in a form prescribed by the CA and that 
> complies with these Requirements

This occurs “Prior to the issuance” and therefore before “the date the 
Certificate issues”.  So at the time the CA is responsible for confirming that 
validations have been performed, the CA already has “obtain[ed] from the 
Applicant a certificate request”.

You ask ‘how do you do the validations without an Applicant’.  The question is, 
as I said, incorrect, in that at the relevant time it is clear who the 
Applicant is, but here’s an example which answers what I think is the better 
question, which is how you do the validations first and obtain the request 
later:

1. A new user creates an account in a CA’s system, identified by username and 
password
2. The new user indicates they would like to validate example.com as controlled 
by them
3. The CA’s system looks up example.com in whois and sends an e-mail to the 
administrative contact, ad...@example.com
4. The user, who is logged in, confirms they received the e-mail by supplying 
the random token
5. The user, who is logged in, now asks for a DV certificate for 
site.example.com
6. The user, who is logged in, accepts the subscriber agreement for this and 
all future certificates
7. The user, who is logged in, supplies a CSR for the request
8. The certificate issues, based on the user being the Applicant, step 5 being 
the request (and step 7 being ‘additional information’), and step 4 being the 
domain validation.

Now, do you think this certificate is mis-issued under the BRs?  Does it matter 
if after this process, it continues:

9. A few minutes later, the user, who is still logged in, now asks for another 
DV certificate for site2.example.com
10. The user, who is logged in, supplies a CSR for the request
11. The certificate issues, based on the user being the Applicant, step 9 being 
the request (and step 10 being ‘additional information’), and step 4 being the 
domain validation.

Is this mis-issued?

> On 22 May 2017, at 8:18 am, Ryan Sleevi  wrote:
> 
> How do you do _any_ of the validations without an Applicant, and how do you 
> have an Applicant without a request - that was the core question.
> 
> On Mon, May 22, 2017 at 4:46 AM, Geoff Keating  wrote:
> All the BRs say is that a request has to happen before a certificate is 
> issued.  They don’t say a request has to happen before any validations occur.
> 
> A CA issues a certificate following a request, and must have performed the 
> validations that match that request.  There is no requirement that 
> validations were originally performed in the context of a specific request.
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Preballot - Revised Ballot 190

[Geoff Keating via Public]

All the BRs say is that a request has to happen before a certificate is issued. 
 They don’t say a request has to happen before any validations occur.

A CA issues a certificate following a request, and must have performed the 
validations that match that request.  There is no requirement that validations 
were originally performed in the context of a specific request.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Preballot - Revised Ballot 190

[Geoff Keating via Public]

> On 19 May 2017, at 3:43 pm, Ryan Sleevi  wrote:
> 
> How does that fit with the quoted Section 4.1.2?
> 
> "The  certificate request MUST contain a request from, or on behalf of, 
> the Applicant for the issuance of a Certificate, and a certification by, or 
> on behalf of, the Applicant that all of the information contained therein is 
> correct.”

4.1.2 starts with “Prior to the issuance of a Certificate”.  So, at some point 
before the certificate issues, 4.1.2 needs to be satisfied.  There’s no 
ordering between that and the validation requirements in the BRs.

> 1) If there is no certificate request, is there an Applicant at the time the 
> CA begins validating information?

A validation is only relevant to the BRs if it leads to a certificate issuance. 
 A certificate issuance must only occur after a certificate request which 
implies the existence of an Applicant to get the certificate request from.  So, 
yes, there must have been an Applicant.  The CA may not have known who.

> 2) If there is no certificate request, and/or there is no Applicant, how is 
> the information the CA validated conforming with Section 3.2, which Section 
> 4.2.1 references?

There is always an Applicant and there must be a certificate request, see above.

> Those are two reasons why I do not believe the scenario is permitted.

Those weren’t reasons, they were questions…

> On Fri, May 19, 2017 at 6:37 PM, Geoff Keating  > wrote:
> Hi Ryan,
> 
> I don’t think there’s anything in the BRs that says that particular 
> validation steps must happen before other steps, so long as the appropriate 
> time limits are honored.  Your example where a CA finds an existing 
> certificate for a prospective customer, validates everything in that 
> certificate (for example checking domain name against organization name using 
> whois), and then contacts the prospective customer (for example, via postal 
> address in company registration, matched against whois) and asks if they’d 
> like a replacement certificate and if all the details are correct, seems 
> permitted to me.
> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Preballot - Revised Ballot 190

[Geoff Keating via Public]

Hi Ryan,

I don’t think there’s anything in the BRs that says that particular validation 
steps must happen before other steps, so long as the appropriate time limits 
are honored.  Your example where a CA finds an existing certificate for a 
prospective customer, validates everything in that certificate (for example 
checking domain name against organization name using whois), and then contacts 
the prospective customer (for example, via postal address in company 
registration, matched against whois) and asks if they’d like a replacement 
certificate and if all the details are correct, seems permitted to me.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] streetAddress

[Geoff Keating via Public]

> On 17 May 2017, at 11:25 pm, Adriano Santoni  
> wrote:
> 
> Here is an example:   (please note: it's a fake one, generated via an 
> on-line fake address generator)
> 
> O=ACME SA
> STREET=38, Place Charles de Gaulle, 76600 Le Havre, France
> L=Le Havre
> ST=Seine-Maritime
> C=FR
> 
> In the above example, streetAddress not only contains a street name and house 
> number, but other info as well, including the locality (already specified in 
> the separate localityName attribute) and the country (already specified in 
> the separate countryName attribute), and a postal code that should probably 
> be moved elsewhere (e.g. in the specific postalCode attribute, if used).
> 
> It is quite obvious, in the above example, that the address information are 
> consistent, overall. The question I am asking is: is this way of populating 
> streetAddress okay, from a compliance point of view?
> 
> Does anybody think that such a certificate should be regarded as 
> non-conformant to the BRs ?

It’s not ‘non-conformant’, exactly; the word I would use is ‘wrong’.  It means 
something but it does not mean what the author thinks it means.

The above corresponds to an address that might look like this when placed on an 
envelope:

ACME SA
38, Place Charles De Gaulle, 76600 Le Havre, France
Le Havre, Seine-Maritime
FRANCE

Probably the envelope will be delivered, but it’ll be rejected by auto-sorting 
machines and require manual processing.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion Revisions

[Geoff Keating via Public]

The ‘ballot’ is the thing that includes the ‘redline or comparison’, bylaws 
section 2.3(a).  If it doesn’t have one of those, it’s not a ballot.  So the 
redline is definitely part of the ballot and if there’s some confusion it can 
be consulted to make it clear what change was voted on.

In addition, the redline has to be against a specific version of the 
guidelines.  If that wasn’t done properly, to the point where there’s a 
question as to what the ballot means or where votes might have been made based 
on the incorrect information, then I’d think the ballot would be invalid.

> On 16 May 2017, at 1:15 pm, Ryan Sleevi via Public  
> wrote:
> 
> Yup. I'm curious for Apple's and Amazon's feedback, since they've been most 
> active in bylaw discussions :)
> 
> We've got several paths to clear this up, hence my straw poll outlining 
> options I could think of that would allow us to do so (trying to do so w/in 2 
> weeks - e.g. prior to the IP Review period expiring)
> 
> On Tue, May 16, 2017 at 3:44 PM, Ben Wilson  > wrote:
> I think the end goal is to have a version 1.6.3 of the EV Guidelines with the 
> language indicated in the redlined version of Appendix F that I circulated a 
> short while ago.  So I’d prefer that we find there was no ambiguity and that 
> Kirk start the review period over with the correct language and we call that 
> good, but of course the cleanest route would be that Ballot 198 be declared 
> defective because of ambiguity and a new ballot be presented for a new vote.  
> Fortunately this issue only affects the EV Guidelines, which doesn’t have any 
> ballots in play, as far as I know. <>
>  
> 
> From: Ryan Sleevi [mailto:sle...@google.com ] 
> Sent: Tuesday, May 16, 2017 12:39 PM
> To: CA/Browser Forum Public Discussion List  >
> Cc: Ben Wilson >
> Subject: Re: [cabfpub] Revised Notice of Review Period - Ballot 198 - .Onion 
> Revisions
> 
>  
> 
> As Ben has highlighted, the result of 198 created a new set of issues.
> 
>  
> 
> Kirk's original message includes the full text of the ballot (MOTION BEGINS), 
> which, unfortunately, used text different from what was adopted in Ballot 144 
> (and part of the current EVGs) when Jeremy made his modifications.
> 
>  
> 
> In examining 198 - 
> https://cabforum.org/pipermail/public/2017-April/010706.html 
>  - it's clear 
> in Jeremy's redlined versions (which, mistakenly, I reviewed as truth), the 
> 'intent' was a small change. See 
> https://cabforum.org/pipermail/public/attachments/20170424/80683ba2/attachment-0001.pdf
>  
> 
>  
> 
> However, as Balloted, it requires a full replacement of the text adopted in 
> 144, in a way that's structurally incompatible with the ASN.1 encoding.
> 
>  
> 
> Worse, this is something that was discussed during the voting reform 
> discussions - both situations where redlines and text differ (as in this 
> case) and questions about redlining as 'source of truth'. We tried to address 
> it as best as possible, but also somewhat punted the issue as unlikely :)
> 
>  
> 
> I think it's worth highlighting this concern broadly, because we have several 
> possible interpretations:
> 
>  
> 
> 1) The MOTION BEGINS/MOTION ENDS is authoritative (e.g. as Kirk has 
> distributed)
> 
>   - In this case, we've now introduced a bug into the processing that is not 
> easily undone.
> 
>   - Supporting Argument: This is how we've always done things.
> 
>   - Solution Suggestion: Hold a ballot immediately to try to fix this before 
> the end of the IP review.
> 
> - Approach 1: Nullify the ballot? That is, to keep the version of the BRs 
> the same.
> 
> - Approach 2: Direct the Chair not to publish any new versions of the BRs 
> (thus triggering compliance for CAs) until the matter is resolved
> 
> - Approach 3: Introduce a new ballot with a new OID for the service 
> descriptor that restores the 144 text
> 
>   - Implications:
> 
> - If folks don't vote on this, we're stuck in a bad place (effectively, 
> no one should issue EV onion certs, because they'd post a compat/interop risk)
> 
>  
> 
> 2) The redline text is authoritative (e.g. as Ben has distributed)
> 
>   - In this case, we're saying that the PDFs, not the ballot text, are what 
> is authoritative.
> 
>   - This means you can no longer read ballots on our website "as is", but 
> must ALSO view/post the supporting materials
> 
>   - Supporting Argument: The Bylaws seem to support this with respect to 
> Section 2.3(a).
> 
>   - Solution Suggestion: Hold a ballot to agree on this interpretation for 
> this specific ballot
> 
>   - Solution Suggestion p2: Hold a 

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Geoff Keating via Public]

In this particular case, because issued certificates contain the subject name 
from the issuer, you could argue that issuance from a CA without a subject name 
is no longer allowed—7.1.4.1 says that the issuer name must match the subject 
name of the issuer (of course!), and that brings the issuer's name into scope 
at the time of issuance.  This is different from other properties of the 
issuer’s certificate, like the algorithm it is signed with or its expiry date, 
because those don’t propagate to the issued certificate.

Or not.  You can make arguments either way.

> On 4 May 2017, at 1:06 pm, Ryan Sleevi  wrote:
> 
> How so? The Ballot only applies to the profile of the issuance of 
> roots/sub-CAs, not from.
> 
> If it applied to from, the existing BRs would already rule out a number of 
> members' roots and intermediates :)
> 
> 
> On Thu, May 4, 2017 at 4:04 PM, Geoff Keating  > wrote:
> 
>> On 4 May 2017, at 12:30 pm, Ryan Sleevi via Public > > wrote:
>> 
>> Kirk raised that, but it does not seem to be a founded concern.
>> 
>> 1) That requirement applies to all certificates issued against the current 
>> BRs
>> 2) The BRs do not retroactively invalidate - or, especially in the case of 
>> Ballot 197 - approve - certificate issuance.
>> 
>> A CA has always and only been obligated to state compliance with the 
>> in-force BRs with respect to issuance and its activities.
> 
> In this context, saying the BRs apply to ‘all certificates issued’ might mean 
> that you could no longer issue a certificate against a root without a common 
> name, and so cannot renew any sub-CAs.
> 
>> On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public > > wrote:
>> Gerv, could we also request explicit forward-looking language? Kirk raised 
>> the concern about whether this applies to existing roots and intermediates. 
>> We have a root issued in 1997 that does not have a common name. Some 
>> interpretations have been discussed, but we would strongly prefer that this 
>> be written into this change for clear future interpretations.
>> 
>>  
>> 
>> If I may:
>> 
>>  
>> 
>> 7.1.4.3. Subject Information – Root Certificates and Subordinate CA 
>> Certificates
>> 
>> When issuing a Root Certificate or Subordinate CA Certificate, the CA 
>> represents that it followed the procedure set forth in its Certificate 
>> Policy and/or Certification Practice Statement to verify that, as of the 
>> Certificate’s issuance date, all of the Subject Information was accurate and 
>> included the content required by this section.
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXT] Re: Ballot 199 - Require commonName in Root and Intermediate Certificates

[Geoff Keating via Public]

> On 4 May 2017, at 12:30 pm, Ryan Sleevi via Public  
> wrote:
> 
> Kirk raised that, but it does not seem to be a founded concern.
> 
> 1) That requirement applies to all certificates issued against the current BRs
> 2) The BRs do not retroactively invalidate - or, especially in the case of 
> Ballot 197 - approve - certificate issuance.
> 
> A CA has always and only been obligated to state compliance with the in-force 
> BRs with respect to issuance and its activities.

In this context, saying the BRs apply to ‘all certificates issued’ might mean 
that you could no longer issue a certificate against a root without a common 
name, and so cannot renew any sub-CAs.

> On Thu, May 4, 2017 at 3:27 PM, Steve Medin via Public  > wrote:
> Gerv, could we also request explicit forward-looking language? Kirk raised 
> the concern about whether this applies to existing roots and intermediates. 
> We have a root issued in 1997 that does not have a common name. Some 
> interpretations have been discussed, but we would strongly prefer that this 
> be written into this change for clear future interpretations.
> 
>  
> 
> If I may:
> 
>  
> 
> 7.1.4.3. Subject Information – Root Certificates and Subordinate CA 
> Certificates
> 
> When issuing a Root Certificate or Subordinate CA Certificate, the CA 
> represents that it followed the procedure set forth in its Certificate Policy 
> and/or Certification Practice Statement to verify that, as of the 
> Certificate’s issuance date, all of the Subject Information was accurate and 
> included the content required by this section.


smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Forbid DTPs from doing Domain/IP Ownership Validation ballot draft

[Geoff Keating via Public]

> On 27 Apr 2017, at 11:57 am, Kirk Hall  wrote:
…
> You have identified one case where an external RA (DTP) was not known to you 
> -- I believe it was the Korean partner of Symantec, right?  Have you 
> encountered any other cases that are similar?
> 
> In the Symantec case, you and Google have taken major action involving 
> Symantec, the Korean DTP, and I think even the Korean auditor.  Is that not 
> sufficient?

The point here is that we would like not to have to do that again.

The problem wasn’t just one DTP; in fact, there were two distinct problems, 
there was one DTP who had an apparently clean audit but had some improperly 
issued certificates, and then when the audits for the other DTPs were examined, 
there were a variety of irregularities.  This proposal is addressing the second 
problem.

> Why not require CAs to list all DTPs relied on as an appendix to their 
> audits, with links to the related audits of the DTPs?  I think Geoff 
> suggested something like that (and he was in the same meeting I was, and 
> presumably heard all the same discussion I did - no malice there).

Not exactly.  My alternative was that all the DTPs be audited in the same audit 
as the CA.  One audit report signed by one auditor, no links, no mismatched 
timeframes, no qualifications on the DTP that don’t get reflected in the CA’s 
audit, and definitely no missing audits.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Forbid DTPs from doing Domain/IP Ownership Validation ballot draft

[Geoff Keating via Public]

> On 26 Apr 2017, at 5:12 pm, Kirk Hall via Public  wrote:
> 
> Ryan, you kind of skipped over a core rationale for this draft ballot – that 
> it’s somehow too hard to audit DTPs (at least as to their domain validation 
> activities).  Why is it too hard?
>  
> Here is what the Purpose section of the ballot says:
> Purpose of Ballot: At the moment, CAs are permitted to delegate the process 
> of domain and IP address validation. However, permitting such delegations is 
> problematic due to the way audits work - the auditing of such work may or may 
> not be required and, if it is, those audit documents may not make it back to 
> root programs for consideration. Although the audit situation also needs 
> fixing, domain validation is an important enough component of a CA's core 
> competencies that it seems wiser to remove it from the larger problem and 
> forbid its delegation. The purpose of this ballot is to ensure that CAs or 
> their Affiliates are always the ones performing domain/IP address ownership 
> validation for certificates that CA is responsible for.
>  
> Can you and/or Gerv explain why auditing of DTPs can’t be fixed? 

An alternative approach would be to require that audits include all DTPs 
involved in domain validation (or, all DTPs no matter what they do) in the 
scope of the CA’s audit; so there would be one audit which covers the CA and 
all DTPs over the audit timeframe.  My understanding from the discussion at the 
last F2F is that the auditors and CAs did not think this would be feasible in 
typical cases.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Agenda for CABF teleconference April 27

[Geoff Keating via Public]

> On 24 Apr 2017, at 2:07 pm, Ryan Sleevi via Public  
> wrote:
> 
> I thought it was concluded that Ballot 194 had failed, but if there's still 
> ambiguity, we should resolve that post-haste.

There’s definitely ambiguity.

However, the Chair has tabulated and announced the results as required by 
2.3(d).  In one interpretation of the Bylaws he did it wrong, but it is now too 
late; there is no provision in the Bylaws to challenge the tabulation or even 
for the Chair himself to correct it once 3 business days have passed, and the 
bylaws state that the Chair is performing the tabulation on behalf of the 
entire Forum.  The Forum’s tabulation said the ballot passed.  So I believe it 
passed.

…
> I would hope such a Ballot would provide complete guidance on such matters, 
> by addressing Ballot 194's status, the "Review Notice", the clarifications on 
> voting (e.g. sent, submitted, posted, delivered, via shall all be measured by 
> this means). As this would not affect any of the documents, we could complete 
> such a vote within 14 days.

I agree we should fix the bylaws to reduce ambiguity.

> I'm curious whether there are any other concerns that such a Ballot should 
> try to address so that there is no ambiguity whatsoever with respect to 
> Ballot 194's status, and which might serve as a model for the future in the 
> determination of such ambiguity. This is similar to the readoption of our 
> documents in Ballots 180 - 182, to attempt to resolve such ambiguities.

Well, do we want to explicitly state that the Chair’s ruling is final?  Or 
would we like some other resolution mechanism?

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

[Geoff Keating via Public]

> On 18 Apr 2017, at 3:14 pm, Jeremy Rowley via Public  
> wrote:
> 
> What is the strained interpretation? Seems logical to me. I also disagree 
> that the energy can be better spent. This is a good exercise and shows that 
> regardless of the ballot outcome, we should fix the confusion in bylaw 
> wording.
>  
> The argument is about the process at this point is more interesting than the 
> results. We can’t maintain discipline about the process if we can’t figure 
> out what the process even is.

If it helps, I think I’ve figured out why different people are interpreting 
this differently.

A technical person will read “Public Mail List” as meaning a server, a web site 
and e-mail relay.  A non-technical person will read it as meaning a list, of 
people or e-mail addresses.

You can read the whole document with each of these meanings in your head and 
never once hit a definite contradiction, although it’s clear that different 
bits of the document were written by people with different ideas about what it 
meant; compare "The Chair will notify both the Member Mail List and the Public 
Mail List of the approval” in 2.3(i)(A) with "all such separate list-servs must 
be managed in the same fashion as the Public Mail List” in 5.3.

But ‘submitting’ something to a server is the meaning of 'submit’ that is 'to 
present or propose to another for review, consideration, or decision’ and 
allows the server to reject it, while ‘submitting’ something to a list of 
people is the other meaning of ‘submit’, ‘to deliver formally’, and you haven’t 
delivered it if it didn’t arrive.


So, you’re all right and you’re all wrong, I hope that helped!


A bigger problem we have is that we have no way to resolve this issue.  There 
has been a vote, and it either passed or it didn’t, and the bylaws are 
ambiguous on which is the case.  So I think that what we need most of all is a 
resolution mechanism.  One simple one is to say that the Chair’s ballot count 
is definitive.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL]Re: ]RE: Ballot 194 - Effective Date of Ballot 193 Provisions is in the VOTING period (ends April 16)

[Geoff Keating via Public]

I’m really not sure what the issue is here.  Microsoft sent their vote to the 
public mailing list before the deadline.  The message was posted on the public 
mailing list (by Kirk) in a reasonably timely manner.  I don’t see any conflict 
with the bylaws.

I agree it would have been better if the vote had appeared on the list at the 
time it was sent.

I also see no point in litigating this.  If this ballot fails solely for this 
reason it will surely be submitted again and will pass.  In fact I would lobby 
for Apple to support the re-ballot instead of abstaining, purely to discourage 
rules lawyering.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Naming rules

[Geoff Keating via Public]

Although these are all good points, it’s worth mentioning that the BR rules for 
what has to go in a subject name are intentionally quite lax, because after 
all, you can just omit the whole thing and issue a DV certificate.  So I think 
it’s somewhat intentional that you can have certificates for different entities 
that look the same.

Perhaps a more interesting question is this: suppose you were issuing an OV 
certificate and you wanted to do it really well, so you were going to fill in 
all the information just like it was EV (but presumably without the more 
extensive EV checks).  In this case, you’d fill in streetAddress for the Delano 
example below, wouldn’t you?  (After checking that it matches the address on 
the DBA registration form, presumably—but without the site visit you would need 
to do for a real EV certificate.)  And maybe also fill in 
jurisdictionOfRegistration if these were real legal entities.

So maybe this is another case where we want to try to converge the BR and EV 
standards, and have OV just be an EV certificate with data missing and less 
validation.

> On 26 Mar 2017, at 9:41 am, Peter Bowen via Public  
> wrote:
> 
>> 
>> On Mar 25, 2017, at 1:20 PM, Peter Bowen via Public  
>> wrote:
>> 
>> 
>>> On Mar 25, 2017, at 12:53 PM, Ryan Sleevi  wrote:
>>> 
>>> On Sat, Mar 25, 2017 at 3:38 PM, Peter Bowen  wrote:
>>> Who cares if there are collisions in cert subjects?  We already have that 
>>> possibility and this doesn’t really change that.
>>> 
>>> Can you provide an example using the current validation requirements? I 
>>> would think that the need for names to be meaningful and the validation 
>>> procedures would exist to disambiguate these names by using a unique (for 
>>> purpose) construction.
>> 
>> We allow individual names in certificates.  There is zero requirement that 
>> only one person with an unique name live in the same city.  Growing up we 
>> used to routinely get calls for someone who had the same name as my father 
>> who lived all of three blocks from us.
>> 
>> Additionally, looking at https://arcc.sdcounty.ca.gov/pages/fbn-info.aspx it 
>> explicitly says:
>> 
>> "All prospective registrants are cautioned that REGISTRATION OF A FICTITIOUS 
>> NAME DOES NOT GUARANTEE EXCLUSIVE USE OF THAT NAME.”
> 
> In addition to this, it notes that there is no state registration of 
> fictitious names, it is handled at the county level.  However communities 
> (localities) can span county lines.  For example:
> 
> 1998 ROAD 152
> DELANO CA 93215-9437
> is in Tulare County, while
> 
> 728 MAIN ST
> DELANO CA 93215-2936
> is in Kern County.
> 
> Under California law and according to the BRs, two unrelated businesses, if 
> they had these addresses, could each be validated for:
> 
> /C=US/ST=California/L=Delano/O=Turquoise Haberdashery
> 
>>> Would it help if we moved the Subject Identified requirements to an overlay 
>>> guideline such that the BRs only covered Internet-scope validation (e.g. 
>>> just dNSName, ipAddress, SRVName, and maybe rfc822Address)?
>>> 
>>> And commonName
>> 
>> OK.  If the BRs only covered GeneralNames in the SubjectAlternativeName 
>> extension of types dNSName, ipAddress, rfc822Address and otherName (of type 
>> SRVName) and Subject Attributes of type commonName, would that help?
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Why HSMs?

[Geoff Keating via Public]

> On 25 Mar 2017, at 10:30 am, Peter Bowen via Public  
> wrote:
> 
> This week we had a discussion on future signature algorithms, one of the 
> items raised is that we don’t have HSMs that support many of the algorithms 
> and that even if we do, they are not included in FIPS 140-2.
> 
> I wanted to take a step back and ask kind of a stupid question: why do we 
> require HSMs?  Do we have a threat model that was used as input to the 
> decision to require HSMs?
> 
> I’m asking because it seems important to understand how we got to this point 
> before we consider what items we can drop or alter as we look to revise the 
> requirements to support new algorithms.

The canonical reason to require a HSM is so that the key cannot be extracted, 
and therefore even in the event of a compromise, the damage is limited to any 
signing operations performed in a particular time period.  (Of course it helps 
a lot if the compromise is not so extensive that you can’t trust the logs and 
so know what signing operations were actually performed.  You really win if you 
discover no signing operations were performed!)

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Geoff Keating via Public]

> On Mar 20, 2017, at 5:59 AM, Dimitris Zacharopoulos  wrote:
> 
> On 20/3/2017 11:05 πμ, Geoff Keating wrote:
>> 
>> I also do not see where the EU has actually approved, requested, suggested, 
>> or even hinted at the use of this value in certificates.  A specific 
>> reference would be needed.
> 
> Looking the other way won't change the fact that these well-defined 
> exceptions have been properly documented in the 1501/2015 decision. I have 
> not read the minutes of the corresponding EU proceedings but it is strange 
> you suggesting they were not properly requested, suggested and approved 
> through the official EU channels.

I did not say that.  I have no opinion on that.  What I was trying to say is 
that the decision you quoted, which I have read, does not seem to document 
these ‘well-defined exceptions’ in the context of the countryName field in a 
certificate.

>> Likewise Greece; but Greece is literally the last country in the world that 
>> I can imagine saying that an international body should be ignored in favor 
>> of a country's preferred nomenclature, because of their dispute over 
>> Macedonia.
> 
> This is clearly a political statement that is out of the Forum's usual line 
> of arguments (at least for the years I participate). I may have a personal 
> opinion on political issues (about "FYROM") but refrain from making political 
> statements in a technically oriented standards group like the CA/B Forum. 
> Having said that, I will not judge right or wrong or question the reasoning 
> behind official EU, Greek, US laws. I think this is also in the spirit of 
> 9.16.3 where "local law" supersedes the BRs in case of a conflict between the 
> two. I suggest we avoid making similar political statements.

I did not intend to make a political statement; and to be very clear, I am not 
expressing any opinion on the dispute other than that it exists.  I seem to 
have hit a sensitive topic, which was not my intention, and I apologise for any 
bad feelings that may have resulted.

I do not think we can decide on the naming or coding of countries without it 
becoming political, and I do not think we can have a political discussion 
without causing bad feelings.  So I think the CABforum should not become 
involved, and leave the topic to the ISO.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

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

[Geoff Keating via Public]

In this discussion, I think perhaps a key point has been lost:

Why is the CABforum involved in this?

The CABforum does not assign country codes, nor is it responsible for defining 
the countryName attribute (that’s in ITU-T X.520 | ISO/IEC 9594-6).  I don’t 
see why the CABforum should consider itself free to change that definition and 
I don’t see why people should be asking it to.

Even if it was permitted, would it be wise?  The CABforum is not well suited to 
be determining the existence or names of countries, especially in contentious 
cases, and there are a lot of contentious cases in this area.  An important 
function of the ISO 3166 Maintenance Agency is to enfold these contentious 
cases in careful bureaucracy and to come up with a result that, while it might 
not be agreed to be the correct result, or the desirable result, is at least 
agreed to be the result.



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Certificate lifetimes: end state or trajectory?

[Geoff Keating via Public]

> On 3 Mar 2017, at 3:27 pm, Peter Bowen via Public  wrote:
> 
> I think that “algorithm” should be taken in a broader context that just 
> cryptographic algorithm.  For example, when looking at the validation method 
> that allows domain validation via a change on a website, we found several 
> issues:
> 
> - A number of websites will echo back the URI path in the response body 
> (https://cabforum.org/pipermail/public/2016-April/007504.html) and will 
> return HTTP 200 for any path.  This means a validation process that is 
> “ensure that GET /.txt returns 200” or “GET / value>.txt returns ” is vulnerable
> - A number of websites allow users to create content (e.g forums).  This 
> means any validation process that is “here is .  Put it on 
> your web server and give us the path to it” is vulnerable
> 
> The changes in ballot 169 attempt to mitigate these risks, but there are lots 
> of existing certs out there that passed validation using some variant of one 
> of these methods.  One option is to just require CAs revoke all existing 
> certificates that were issued using website control validation, but this 
> would be highly impactful to customers.  The other option is to cease using 
> the vulnerable method and let the existing certs expire.  In this case the 
> maximum validity period defines how long potentially mis-issued certificates 
> are live.
> 
> Assuming we agree on the principle of least surprise, revocation is a far 
> worse choice than leaving the certificate live until expiration.  However we 
> still want bound how long this transition period will last. In most cases, 
> the validity period of certificates is the largest driver of the duration of 
> the transition period; by shortening it we shorten there transition period.  
> So I disagree with your premise; there is a security benefit to shorter 
> certificates, just like there is a security benefit to more frequent software 
> updates.

I thought this was interesting in the context of automatically updating 
certificates.  Imagine the scenario where most certificates are 90-day, 
automatically requested and validated, using a method like the broken one 
above.  We find the problem described above and want to make a change.  So, 
give a 6 month implementation period for CAs, and 9 months later all unexpired 
certificates have been issued with the new method, right?  No!  Now not only 
must CAs make a change, but millions of devices must make a change, which puts 
the provided token in a different place in their web site.  Some will take 
years to have the change deployed.  Some custom systems will need to do it as 
part of a regular release cycle, and might want engineering resources scheduled 
a year in advance.  Some abandoned devices might never make the change and need 
to be upgraded by replacement, or need a manual exception method.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Ballot 185 (Revised) - Limiting the Lifetime of Certificates

[Geoff Keating via Public]

> On 21 Feb 2017, at 8:16 am, Ryan Sleevi via Public  
> wrote:
> 
> 
> 
> On Mon, Feb 20, 2017 at 6:23 PM, Curt Spann via Public  > wrote:
> Apple votes Abstain.
> 
> Curt
> 
> Curt,
> 
> To the extent you can comment for Apple, can you clarify whether the 
> abstention is related to:
> - Duration of validity (13 months)
> - Time to phase in (6 months)
> - Other?

We discussed this inside Apple, and came to the conclusion that while there was 
probably a small net benefit, there was uncertainty about the benefits and the 
costs, especially on the side of increasing costs, and a possibility the costs 
far outweighed the benefits.  All factors you mention were involved in the 
conclusion.

We would likely support a reduction to 27 months, with a reasonable phase-in 
time.  This would significantly reduce the uncertainty in the cost/benefit 
analysis because it is already in use for EV and because it has had more 
warning time.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Draft Ballot 185 - Limiting the Lifetime of Certificates: User input

[Geoff Keating via Public]

> On Feb 11, 2017, at 10:03 AM, Gervase Markham via Public 
>  wrote:
> 
> So the validity time beyond 12 months of a "1-year" cert is basically
> the time needed to install the cert; you need a bit of extra validity in
> order to keep an annual renewal date. So my question is: when and how
> does it take as much as 3 months to install a cert, and if it does,
> isn't something seriously broken?

Suppose you have a very large system on which many people rely.  It would be 
irresponsible to just directly install a certificate on each of the front-end 
hosts, especially if something had changed such as a new intermediate or a 
different algorithm; prudent practice would be to initially put it on a QA 
system, test that against all relevant clients, move to a staging host that is 
identical to production but not actually used by clients, confirm it does 
function there, then deploy in a gradual fashion to the actual production hosts.

This process can easily take more than a month.

Now, normally, the new certificate is the same as the old one except for dates 
and the key, those you might deploy initially in staging on the grounds that 
it’ll probably work, but it’s still prudent to do a round of testing.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] [Corrected] Voting has started on Ballot 180 - ends January 7

[Geoff Keating via Public]

Apple votes YES.

(Re-posting to the public list.)

> On 2 Jan 2017, at 10:29 am, Kirk Hall via Public  wrote:
> 
> The voting period for Ballot 180 has started, and will continue until January 
> 7, 2017 at 22:00 UTC.  The ballot is shown below. Voting will occur on the 
> Public list.
>   
>  
>  
> Ballot 180 – Readopting the BRs, EVGL, EV Code Signing, and NCSSR Guidelines 
> with Amendments
>  
> The following motion has been proposed by Kirk Hall of Entrust and endorsed 
> by Peter Bowen of Amazon and Virginia Fournier of Apple as a Final Guideline:
>  
> -- MOTION BEGINS –
>  
> In accordance with the Bylaws and Intellectual Property Rights (IPR) Policy 
> of the CA/Browser Forum (the “Forum”), the following Guidelines:
>  
> ·   Baseline Requirements Certificate Policy for the Issuance and 
> Management of Publicly-Trusted Certificates (BRs)
> ·   Guidelines for the Issuance and Management of Extended Validation 
> Certificates (EVGL)
> ·   Guidelines for the Issuance and Management of Extended Validation 
> Code Signing Certificates, and
> ·   Network and Certificate System Security Requirements,
>  
> all as previously approved by all ballots up to and including Ballot 175, are 
> hereby readopted by this Ballot, with the following amendments.
>  
> 1.  BR 3.2.2.4 is amended to read in its entirety as follows:
>  
> 3.2.2.4 Validation of Domain Authorization or Control
>  
> This section defines the permitted processes and procedures for validating 
> the Applicant's ownership or control of the domain.
>  
> The CA SHALL confirm that, as of the date the Certificate issues, either the 
> CA or a Delegated Third Party has validated each Fully-Qualified Domain Name 
> (FQDN) listed in the Certificate by using any method of confirmation, 
> provided that the CA maintains documented evidence that the method of 
> confirmation establishes that the Applicant is the Domain Name Registrant or 
> has control over the Fully Qualified Domain Name (FQDN).
>  
> Completed confirmations of Applicant authority may be valid for the issuance 
> of multiple certificates over time. In all cases, the confirmation must have 
> been initiated within the time period specified in the relevant requirement 
> (such as Section 3.3.1 of this document) prior to certificate issuance. For 
> purposes of domain validation, the term Applicant includes the Applicant's 
> Parent Company, Subsidiary Company, or Affiliate.
>  
> 2.  EVGL 11.7 is amended to read in its entirety as follows:
>  
> 11.7.1. Verification Requirements
>  
> (1) For each Fully-Qualified Domain Name listed in a Certificate, other than 
> a Domain Name with .onion in the rightmost label of the Domain Name, the CA 
> SHALL confirm that, as of the date the Certificate was issued, the Applicant 
> (or the Applicant’s Parent Company, Subsidiary Company, or Affiliate, 
> collectively referred to as “Applicant” for the purposes of this section) 
> either is the Domain Name Registrant or has control over the FQDN using a 
> procedure specified in Section 3.2.2.4 of the Baseline Requirements. For a 
> Certificate issued to a Domain Name with .onion in the right-most label of 
> the Domain Name, the CA SHALL confirm, as of the date the Certificate was 
> issued, the Applicant’s control over the .onion Domain Name in accordance 
> with Appendix F.
>  
> (2) Mixed Character Set Domain Names: EV Certificates MAY include Domain 
> Names containing mixed character sets only in compliance with the rules set 
> forth by the domain registrar. The CA MUST visually compare any Domain Names 
> with mixed character sets with known high risk domains. If a similarity is 
> found, then the EV Certificate Request MUST be flagged as High Risk. The CA 
> must perform reasonably appropriate additional authentication and 
> verification to be certain beyond reasonable doubt that the Applicant and the 
> target in question are the same organization.
>  
> The proposer and endorsers of this Ballot may withdraw this Ballot at any 
> time prior to completion of the final vote for approval, in which case the 
> Ballot will not proceed further.
>  
> -- MOTION ENDS –
>  
> The procedure for this Maintenance Guideline ballot is as follows (exact 
> start and end times may be adjusted to comply with applicable Bylaws and IPR 
> Agreement):
>  
> BALLOT 180
> Status: Final Guideline
> Start time (22:00 UTC)
> End time (22:00 UTC)
> Discussion (7 days)
> Oct. 25, 2016
> Nov. 1, 2016
> Review Period (Chair to send Review Notice) (60 days). 
> If Exclusion Notice(s) filed, PAG to be created and no further action until 
> PAG recommendations received.
> If no Exclusion Notice(s) filed, proceed to:
> Nov. 1, 2016
> Dec. 31, 2016
> Vote for approval (7 days)
> Dec. 31, 2016
> Jan. 7, 2017
>  
> Votes must be cast by posting an on-list reply to this thread on the Public 
> list.
>  
> A vote in favor of the motion must indicate a clear 'yes' in the response. A 
> 

Re: [cabfpub] Voting has started on Ballot 181 - ends January 7

[Geoff Keating via Public]

Apple votes YES.

(Re-posting to the public list.)

> On 2 Jan 2017, at 10:29 am, Kirk Hall via Public  wrote:
> 
> The voting period for Ballot 181 has started, and will continue until January 
> 7, 2017 at 22:00 UTC.  The ballot is shown below.  Please vote this week on 
> this ballot and also on Ballot 180.  Voting will occur on the Public list.
>  
> 
> Ballot 181 – Readopting BR 3.2.2.4 (Part 1)
>  
> The following motion has been proposed by Kirk Hall of Entrust and endorsed 
> by Peter Bowen of Amazon and Virginia Fournier of Apple as a Final Guideline:
>  
> -- MOTION BEGINS –
>  
> In accordance with the Bylaws and Intellectual Property Rights (IPR) Policy 
> of the CA/Browser Forum (the “Forum”), the Forum Baseline Requirements (BR) 
> and Extended Validation Guidelines (EVGL), as previously approved by all 
> ballots up to and including Ballot 176, are hereby readopted by this Ballot, 
> with the following amendments.
>  
> 1.  BR 3.2.2.4 is amended to read in its entirety as follows:
>  
> 3.2.2.4 Validation of Domain Authorization or Control
>  
> This section defines the permitted processes and procedures for validating 
> the Applicant's ownership or control of the domain.
>  
> The CA SHALL confirm that, as of the date the Certificate issues, either the 
> CA or a Delegated Third Party has validated each Fully-Qualified Domain Name 
> (FQDN) listed in the Certificate using at least one of the methods listed 
> below.
>  
> Completed confirmations of Applicant authority may be valid for the issuance 
> of multiple certificates over time. In all cases, the confirmation must have 
> been initiated within the time period specified in the relevant requirement 
> (such as Section 3.3.1 of this document) prior to certificate issuance. For 
> purposes of domain validation, the term Applicant includes the Applicant's 
> Parent Company, Subsidiary Company, or Affiliate.
>  
> Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the 
> subjectAltName extension or in Subordinate CA Certificates via dNSNames in 
> permittedSubtrees within the Name Constraints extension.
>  
> 3.2.2.4.1 [Reserved] 
>  
> 3.2.2.4.2 [Reserved] 
>  
> 3.2.2.4.3 [Reserved]
>  
> 3.2.2.4.4 [Reserved]
>  
> 3.2.2.4.5 Domain Authorization Document
>  
> Confirming the Applicant's control over the requested FQDN by relying upon 
> the attestation to the authority of the Applicant to request a Certificate 
> contained in a Domain Authorization Document. The Domain Authorization 
> Document MUST substantiate that the communication came from the Domain 
> Contact. The CA MUST verify that the Domain Authorization Document was either 
> (i) dated on or after the date of the domain validation request or (ii) that 
> the WHOIS data has not materially changed since a previously provided Domain 
> Authorization Document for the Domain Name Space.
>  
> 3.2.2.4.6 Agreed-Upon Change to Website
>  
> Confirming the Applicant's control over the requested FQDN by confirming one 
> of the following under the "/.well-known/pki-validation" directory, or 
> another path registered with IANA for the purpose of Domain Validation, on 
> the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS 
> over an Authorized Port:
>  
> 1. The presence of Required Website Content contained in the content of a 
> file or on a web page in the form of a meta tag. The entire Required Website 
> Content MUST NOT appear in the request used to retrieve the file or web page, 
> or
>  
> 2. The presence of the Request Token or Request Value contained in the 
> content of a file or on a webpage in the form of a meta tag where the Request 
> Token or Random Value MUST NOT appear in the request.
>  
> If a Random Value is used, the CA or Delegated Third Party SHALL provide a 
> Random Value unique to the certificate request and SHALL not use the Random 
> Value after the longer of (i) 30 days or (ii) if the Applicant submitted the 
> certificate request, the timeframe permitted for reuse of validated 
> information relevant to the certificate (such as in Section 3.3.1 of these 
> Guidelines or Section 11.14.3 of the EV Guidelines).
>  
> Note: Examples of Request Tokens include, but are not limited to: (i) a hash 
> of the public key; (ii) a hash of the Subject Public Key Info [X.509]; and 
> (iii) a hash of a PKCS#10 CSR. A Request Token may also be concatenated with 
> a timestamp or other data. If a CA wanted to always use a hash of a PKCS#10 
> CSR as a Request Token and did not want to incorporate a timestamp and did 
> want to allow certificate key re-use then the applicant might use the 
> challenge password in the creation of a CSR with OpenSSL to ensure uniqueness 
> even if the subject and key are identical between subsequent requests. This 
> simplistic shell command produces a Request Token which has a timestamp and a 
> hash of a CSR. E.g. echo date -u +%Y%m%d%H%M sha256sum  -]//g" The script 

Re: [cabfpub] Ballot process proposal

[Geoff Keating via Public]

> On 17 Nov 2016, at 12:52 pm, Peter Bowen via Public  
> wrote:
> 
> Dear CA/Browser Forum colleagues,
> 
> We have heard a number of concerns about the processes we have been using for 
> ballots and how those processes interact with our IPR policy over the last 
> few weeks.  It has been raised that we don't have a clearly spelled out 
> process.  I've also heard members raise that they don't want to vote to 
> approve something that could end up being adopted with exclusion notices 
> applying.
> 
> Therefore, Amazon proposes to modify our bylaws to reflect that the chair is 
> responsible for approving Draft Guidelines to become Final Guidelines (FG) or 
> Final Maintenance Guidelines (FMG). The chair may only approve by following 
> the process below.
> 
> 1) A ballot among members of the Forum must approve a motion to initiate the 
> adoption process.
> - The ballot may be withdrawn during the review period
> - The ballot may receive small corrections during the review period
> - The ballot must indicate whether it is proposing a Final Guideline (FG) or 
> Final Maintenance Guideline (FMG)
> - The ballot must include either:
>  a) the full text of a Draft Guideline proposed to become a FG or FMG, or
>  b) a set of changes relative to an existing approved FG or FMG
> 
> 2) Within two business days of the announcement of the results of the ballot, 
> if the ballot is valid and is adopted, the Chair shall initiate the Review 
> Period described in the IPR policy.  The review period will be initiated by 
> sending notice to both the Member Mail List and the Public Mail List.  The 
> notice shall include the full text of the Draft Guideline.  If the ballot 
> contained a set of changes relative to an existing FG or FMG, the Draft 
> Guideline is formed by applying the changes to the existing approved FG or 
> FMG.
> 
> 3) At the end of the Review Period (either 30 or 60 calendar days), the Chair 
> shall determine if any Exclusion Notices were received.  If no exclusion 
> notices were received, the Chair shall approve the Draft Guideline, notify 
> the Public Mail List of the Chair's approval, and update the Public Web Site 
> list of FGs and FMGs with the new Guideline.  If exclusion notices were 
> received, the Chair shall not approve adoption of the Draft Guideline, and 
> shall notify the Public Mail List of the disapproval.
> 
> This process ensures that there will never be a case where any member is 
> voting on a guideline that will be adopted with exclusion notices.  It also 
> optimizes to move voting early in the process so that the vast majority of 
> ballots will pass and move to adoption at the end of the review period with 
> no further action, based on the observed set of exclusion notices received 
> upon adoption of IPR policy v1.2.

This is a good policy as far as it goes, but it seems to omit the role of the 
PAG, which might look at the exclusion notices and determine that they don’t 
really apply, are not significant for most members, or similar.  My suggestion 
would be to add:

4) If exclusion notices were received, a PAG shall be formed.  If it recommends 
approval despite the exclusion notices, then a second ballot (including review 
period, but no changes are allowed to the recommendation or the Draft Guideline 
in the review period) must be held to adopt the PAG’s recommendation.  If that 
second ballot passes, then the Chair shall approve the Draft Guideline, notify 
the Public Mail List of the Chair's approval, and update the Public Web Site 
list of FGs and FMGs with the new Guideline.

(There are other things the PAG might recommend, many of which also will turn 
into motions, but only this path allows something to be approved with exclusion 
notices.)

> I believe that adopting this process will only require modifying the bylaws, 
> which we can do via vote, rather than require modifying the IPR policy and 
> getting new IPR agreements from all members.

I agree.

smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Re: [cabfpub] Allowing SHA-1 OCSP and CRL signatures past 2016

[Geoff Keating via Public]

I don’t see the urgency here.  If we follow regular process (that is, allow 
ballot 180 to complete, and then propose ballot 184 in mid-January), it can be 
complete by end February.  This means you can’t issue new OCSP signing 
certificates for a 2-month period, but considering that Entrust’s OCSP 
certificates appear to be valid for 3 years, it doesn’t seem like a huge 
imposition to ask you to check for any that expire in, say, the first half of 
2017 and if so generate a new one before the end of the year.

> On 26 Oct. 2016, at 11:49 am, Ryan Sleevi via Public  
> wrote:
> 
> 
> 
> On Wed, Oct 26, 2016 at 11:45 AM, Kirk Hall  
> wrote:
> I think we may be making too much of all this.  If we have both an old style 
> ballot to make the change now following the procedures in our Bylaws and our 
> past practices, at the very least we will have added the change to our Draft 
> Guidelines with everything else. 
> 
>  
> 
> If we simultaneously add the change to Ballot 180, we will also be following 
> the procedures in our IPR Policy and our new practices, and Ballot 180, once 
> adopted on Jan. 7 will effectively override the previous old style ballot.  
> We would move faster if we could on Ballot 180 to avoid having to follow this 
> process, but it’s not possible.
> 
> 
> Can you explain what you mean by "simultaneously"? I tried to highlight the 
> issue with your proposal before, but perhaps it would be better if you 
> restate.
> 
> We can do several things, but as I see it, your suggestion of "simultaneous" 
> is to vote on 184 while also modifying 180. This implies that the results of 
> 184 are irrelevant for the modification of 180, which seems a dangerous 
> precedent to set, and otherwise pointless to vote on 184.
> 
> If you mean that 180 follows the completion of 184, then it means withdrawing 
> 180, as I explained previously. That's fine, it just means delaying it. 
>  
> So it’s  win-win, and I see no harm from following a dual track for this 
> single time-sensitive issue.  Remember also that the purpose of our IPR 
> Policy is to detect whether or not there are potential IP claims relating to 
> a draft guideline – in this case, I don’t see how Wayne’s proposed amendment 
> could possibly impact anyone’s claimed IP.
> 
> 
> I appreciate your perspective, but I don't believe your perspective provides 
> the legal assurances that members want, and for which our IPR policy is 
> designed to assure. That's the point - we shouldn't be speculating about IP 
> impact, we should follow a consistent process.
> ___
> Public mailing list
> Public@cabforum.org
> https://cabforum.org/mailman/listinfo/public



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public