[cabfpub] Final Minutes of CA/B Forum call Nov 12th 2015

Dean Coclin Dean_Coclin at symantec.com
Tue Dec 8 12:37:13 MST 2015


 

Attendees: Atsushi Inaba, Atilla Biller, Ben Wilson, Billy VanCannon, Bruce
Morton, Connie Enke, Davut Tokgoz, Dean Coclin, Dimitris Zacharopoulos, Doug
Beattie, Eddy Nigg, Gervase Markham, Kirk Hall, Li-Chun Chen, Neil Dunbar,
Patrick Tronnier, Tim Hollebeek, Tim Shirley, Tyler Myers, Volkan Nergiz,
Wayne Thayer

 

1.       Antitrust Statement Read

 

2.       Roll Call completed

 

3.       Agenda Reviewed. 

 

4.       Minutes of 29 October meeting: The minutes were approved and will
be publicized.

 

5.       Ballot Status: The policy working group has 2 ballots (154 and 155)
which are currently open for voting. Other ballots will be coming from
Policy WG. Tim H said we should discuss the policy for what the effective
dates of these ballots should be.  Ballot 153, short lived certificates,
failed earlier in the week. 

 

6.       Proposed Mis-issuance ballot: Sig was unable to join but was
encouraged by the discussions on the mailing list. Dean mentioned that he
received a message from the public in the UK who stated that the HMRC uses
SSL certificates which contain information that should not be public. Gerv
questioned how a CA would vet a value belonging to an individual issued by
the HMRC. Dean said he had just received the information and hadn't had time
to review carefully but would send the link out to the list so others can
review it.

 

7.       Domain Validation Ballot:   Kirk said the Validation Working Group
(VWG) had finished its work on the proposed changes to the Domain Validation
Methods Ballot, and just had five remaining questions to resolve.  The VWG
did not meet the prior week, so Kirk wanted to review the five questions
with the Forum and bring back comments for the next VWG.  He will also pose
the five open questions by an email to the Public list so we can have more
feedback.   

(1)    Richard Barnes of Mozilla suggested we make the following change to
new validation method No. 9:

 

Proposal 1: In line L of draft

CURRENT DRAFT: 

 

"9. Having the Applicant demonstrate control over the FQDN by the Applicant
requesting and then installing a Test Certificate issued by the CA on the
FQDN which is accessed and then validated via https by the CA over an
Authorized Port."

 

Richard proposes to add: "*** or installing a Test Certificate containing a
Random Value or Request Token" as shown:

 

9. Having the Applicant demonstrate control over the FQDN by the Applicant
requesting and then installing a Test Certificate issued by the CA on the
FQDN or installing a Test Certificate containing a Random Value or Request
Token which is accessed and then validated via https by the CA over an
Authorized Port. 

 

Richard's reasoning: "This liberalization would cover the DVSNI proposal
being considered in ACME, and seems to offer equivalent protection to the
other option. (Either way the cert contains something specified by the CA.)"

 

Richard's added language does not specifically say who issues the Test
Certificate - the CA or the Applicant - but it implies the Applicant
generates the Test Certificate.  

 

As a separate question, it is not clear whether the Random Value or Request
Token must come from the CA - Richard's language does not specify that.

 

The defined term Random Value says the value must come from the CA.  The
defined term Request Token says only that the Request Token is a "value
derived in a method specified by the CA from the public key to be certified"
- here is the current definition:

 

Request Token: A value derived in a method specified by the CA from the
public key to be certified. The uniqueness of the Request Token and the
irreversibility of the derivation to be at least as strong as those of the
cryptographic signature algorithm to be used to sign the certificate. 

 

It is unclear exactly how an Applicant receives a Request Token from a CA -
does the CA calculate the value and transmit it to the Applicant to be used
in a practical demonstration?  Or does the CA send the Applicant the
"method" to be used to calculate the Random Value?  There is general
agreement that all "practical demonstration" methods like this one should be
unpredictable and not able to be copied or used by a hacker.  

 

Questions:  (1) Should Richard Barnes' suggested edit be accepted?  (2) Do
we need to edit or clarify either Richard's language or the definition of
Request Token?

 

(2) The second open question for the current Domain Validation ballot also
comes from Richard Barnes of Mozilla, and is as follows.

 

Proposal 2: In line H 

 

CURRENT DRAFT: 

 

"6. Having the Applicant demonstrate control over the requested FQDN by
installing a Random Value (contained in the name of the file, the content of
a file, on a web page in the form of a meta tag, or any other format as
determined by the CA) under "/.well-known/validation" directory on an
Authorized Domain Name, that can be validated over an Authorized Port; or"

 

Richard proposes to add the following language as shown: "*** or any other
path under .well-known registered by IANA for this purpose" 

 

6. Having the Applicant demonstrate control over the requested FQDN by
installing a Random Value (contained in the name of the file, the content of
a file, on a web page in the form of a meta tag, or any other format as
determined by the CA) under "/.well-known/validation" directory on an
Authorized Domain Name, or any other path under .well-known registered by
IANA for this purpose that can be validated over an Authorized Port; or 

 

Richard's reasoning: "For automated systems like ACME, they're going to want
a much more precise definition of the validation process than what's in this
document, and they may want to use different .well-known paths to indicate
different methods that are all compliant with this section. Requiring the
IANA registration allows these differences to exist, but in a controlled
way."

 

On the call, it was noted that only a single path "/.well-known/validation"
directory on an Authorized Domain Name" was chosen intentionally - so that
webmasters could be informed to lock down this path on their websites to
avoid allowing a hacker to post a bogus credential (such as a bogus Random
Value, etc.) and obtain a cert by practical demonstration for a domain they
do not really own or control.  The sentiment on the call was against this
change.  One comment was that if a different path was needed in the future,
it could be discussed and added later by a separate ballot if justified.

 

(3) Peter Bowen of Amazon did not submit specific new language, but posed
the following comment about new Method No. 7 shown below:

 

Proposal 3: In line J of current draft (Method No. 7)

 

"In Item J, it suggests that the random token is only valid for a FQDN
validation.  

 

"I think DNS validation should be allowed for domain hierarchies in addition
to specific FQDNs.  A domain registrant should be able to choose to approve
all FQDNs under  <http://corp.example.com> corp.example.com by adding a
record for  <http://corp.example.com> corp.example.com."

 

Here is the current Ballot language for Method No. 7:

  

"7. Having the Applicant demonstrate control over the requested FQDN by the
Applicant making a change to information in a DNS record for an
Authorization Domain Name where the change is to insert a Random Value or
Request Token; or "

 

Kirk noted we had discussed before the problem of "kirkstore.shopping.com" -
Kirk might have control over the third level FQDN, but might not have
control over the SLDN (Base Domain) of shopping.com, so even though Kirk
could demonstrate control for kirkstore.shopping.com, he should not use that
to get a cert for shopping.com.

 

Doug Beattie thought that Peter might be misreading Authorization Domain
Name, which is defined as follows:

 

"Authorization Domain Name: The Domain Name used to obtain authorization for
certificate issuance or a given FQDN. The CA may use the FQDN returned from
a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the
FQDN starts with a wildcard character, then the CA MUST remove all wildcard
labels from the left most portion of requested FQDN. The CA may prune zero
or more labels from left to right until encountering a Base Domain Name and
may use any one of the intermediate values for the purpose of domain
validation."

 

"Base Domain Name: The portion of an applied-for FQDN that is the first
domain name node left of a registry-controlled or public suffix plus the
registry-controlled or public suffix (e.g. "example.co.uk" or
"example.com"). For gTLDs, the domain  <http://www.[gTLD> www.[gTLD] will be
considered to be a Base Domain. "

 

Questions for Discussion: 

 

(1) Is Doug correct that the current definition of Authorized Domain Name
(see underlined text above) would already satisfy Peter's suggestion that
proving control of any FQDN by making a change to the DNS record for that
FQDN is sufficient to get a certificate for any lower level domain it
contains, including the SLDN or Base Domain?   If yes, are any changes
needed?

 

(2) More generally, do the members agree with Peter's statement that "A
domain registrant should be able to choose to approve all FQDNs under
<http://corp.example.com> corp.example.com by adding a [DNS]record for
<http://corp.example.com> corp.example.com."  If not, do we need to change
the definition of Authorization Domain Name to delete the language
underlined above?

 

(4)  Again, Peter Bowen of Amazon did not submit specific new language, but
posed the following comment about new Method No. 8 shown below:

 

Proposal 4: In line K of current draft (Method No. 8)

 

"Conversely, in item K, using Authorization Domain seems inappropriate.
Just because I control the IP address of  <http://corp.example.com>
corp.example.com doesn't mean I have control
<http://payments.corp.example.com> payments.corp.example.com."

 

Here is the current Ballot language for Method No. 7:

 

[Current Ballot language]

 

8. Having the Applicant demonstrate control over the requested FQDN by the
CA confirming that the Applicant controls an IP address returned from a DNS
lookup for A or AAAA records for the Authorization Domain Name in accordance
with section 3.2.2.5; or 

 

On the call, Wayne Thayer thought he agreed with Peter's comment, and
offered to come up with revised ballot language on this issue.  There was no
other discussion.

 

Question for Discussion: Should proving domain control for an SLDN (Base
Domain) or a FQDN by showing the applicant controls an IP address returned
from a DNS lookup for A or AAAA records be sufficient to show domain control
for all higher level FQDNs also?

 

(5) Richard Wang of WoSign posted the following comment on the pre-ballot:

 

"I think the ballot should include some sort of requirement that a Random
Value, Request Token, or Test Certificate can only be used once by the CA
and customer to validate one domain, and that a new Random Value, Request
Token, or Test Certificate must be generated by the CA for the customer for
each domain being validated, and each time a domain is validated."

 

Currently, there is no limitation on how many times the same Random Value,
Request Token, or Test Certificate (call them all "CA markers") can be used,
or for confirming how many domains, or for what period of time.

 

On the call today, there was general agreement that the CA Markers should
not be reused, but that a new CA Marker should be generated by the CA for
validation of each new domain.  By extension, a CA should also generate a
new CA Marker each time the CA re-validates the same domain (every 13 months
or earlier for EV domains, every 39 months or earlier for DV and OV
domains).

 

There was one suggestion that maybe a CA could use a single CA Marker for
validating all the domains included in a single CSR.

 

Eddy also suggested there should be a time limit on how long a CA Marker
would be valid, as a hacker could perhaps find an unused CA Marker sent to a
domain owner and then use it to get a bogus cert.   For this reason, if the
customer does not use the CA Token in a fairly short period, the CA should
generate and send a new CA Marker to the customer for the domain.

 

Eddy said that applicants are sometimes slow to complete their vetting
process, and so any time limit should not be too short.  He will explain and
offer suggestions in an email.

 

Question for Discussion:  

 

(1) Should all "CA Markers" (Random Values, Request Tokens, Test
Certificates) be prohibited from re-use?  Should the limitation be one of
the following?

(a) CA Markers should only be used one time for one domain being validated
for an Applicant

(b) CA Markers should only be used one time, but can be re-used for
confirming control of multiple domains so long as they are all contained in
one CSR from an Applicant

(c) In any case, no CA Marker may be used more than x days after it has been
generated and issued by the CA to the Applicant - if the domain validation
is not completed in that period, the CA must generate and give a new CA
Marker to the Applicant.

 

What rule(s) should we set for this?

 

8.       Dean asked Gerv about the new Firefox for iOS which is reportedly
not showing a distinction for EV certs. Gerv was unaware of this and
mentioned that it's a version 1 product and perhaps something was amiss. He
will look into it. 

 

9.       Survey results: Dean had sent out a survey to attendees of the
Istanbul meeting to gauge their feeling on face to face speakers. Dean
provided a summary of the survey which included questions on types of
speakers desired and future face to face meetings. He will send out a
summary to the management list.

 

10.   PAG Update: The PAG is almost finished with their task. The PAG did
receive some assertions of essential claims by the 31 October deadline. The
Forum members may have to sign a new IPR policy. There was some confusion as
to the time of the next call and Ben will send out a new invite to clarify. 

 

11.   Validation WG Update: No other updates other than the ballots
discussed above

 

12.   Code Signing WG Update: There will be a call later today to finalize
the draft. There were some minor clarifications to resolve. 

 

13.   Policy WG Update: Update already given above in terms of the ballots.

 

14.   Information WG Update: Meeting canceled for tomorrow. 

 

15.   Other Business: Membership application from Ministry of Interior of
Korea: Dean received the application from said entity which appeared
complete along with a properly signed IPR. However, no evidence of "actively
issuing SSL certificates" was received. Dean will go back and ask for some
examples. Kirk suggested that if we receive this information, then they
should be approved. 

 

16.   Next teleconference scheduled for December 10th

 

17.   Meeting Adjourned

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151208/27cc45fc/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151208/27cc45fc/attachment-0001.bin 


More information about the Public mailing list