[cabf_validation] Minutes from the meeting of 19 July 2018

[Tim Hollebeek]

a) 302 is the simplest and most fundamental redirect (it's at the HTTP
protocol level, and doesn't involve scripts or even content).  If you
consider 302 to be bad, you probably don't like any redirects.  Or at least
shouldn't, to be consistent.

 

Whether redirects to the CA should be allowed or not has been discussed
before; Ryan and the ACME folks are in favor, I'm highly skeptical, as noted
in the validation summit document.  It's possible to completely remove the
domain owner from the validation, and then . what are you validating?

 

b) as far as I'm aware, most CAs are using pki-validation (defined by CABF),
and not the ACME path, as it is older than the ACME one.

 

The rest of the discussion looks good.  Agree on increasingly moving to
narrow, well-focused validation methods.

 

-Tim

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Bruce Morton
via Validation
Sent: Friday, July 20, 2018 11:54 AM
To: CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: [cabf_validation] Minutes from the meeting of 19 July 2018

 

Minutes from the meeting of 19 July 2018.

 

1.	IP address validation, method 6

The risks defined from the validation summit were reviewed.

a.	Forbid CAs from following redirects - There are different kinds of
redirects, some could be an error and some can be a tag that was injected by
a malicious script. Also, should be allow a redirect to go back to the CA,
as this would permanently allow validation by the CA. Is http redirected to
https OK? There are some reasons to have a redirect to allow validation of a
production site from a non-production site. There appears to be many types
of redirects, so it would be good to go to our companies to find out what
types of redirects there are. It was agreed that the method was under
specified, so we need to decide what redirects are okay to use. We need have
specific list of those that are permissible. It was suggested that bad
redirects are 302 and meta refresh tags. Wayne will create a spreadsheet
with the redirects and whether they are acceptable or not acceptable.
b.	Specify exact locations that can be used - The BRs refer to the
.well-known challenge and another path registered by IANA.  We should remove
or any other path and refer to the specific ACME path.
c.	Control of a domain name does not mean control of a subdomain - For
managed accounts and services, base domain are verified and this would allow
subdomains to be used. The point is that DNS is hierarchical and allows
control to be provided someone else, so just because you control example.com
does not mean that you control www.example.com. There were no any concerns
on the call with this issue. Should we use CAA to signal that you are
allowed to validate subdomains. Should we discuss CAA usage on a different
discussion. Should we just keep this item as noted and we will keep track of
it. There could be 2 different validation methods, one that allows
subdomains to be used and one that does not, and CAA could specify which
method is permitted. Or the CAA record could just state whether the
validation applies to subdomains.

 

It was discussed that we want to improved Method 6 and we should focus on
the redirects and the exact locations.

 

2.	CONTACT CAA tag and ballot SC2

This ballot was sent out on July 10, 2018 and is now available for voting.
The ballot is 4 new methods to put email or phone contacts in CAA or DNS
TXT. There is an appendix to address how to use CAA or DNS TXT. This method
should mitigate the GDPR issue.

 

3.	Validation Summit Method 3 ballot

Doug has been putting together a ballot to address issues leave a voice mail
or asked to be transferred. Doug will plan to push out a draft ballot. There
was discussion about using the method if the contact is not a person's name,
such as IT Department. It was discussed that if the Registrant put in IT
Department, then contact someone from the IP Department, get confirmation
and record name.

 

4.	Wayne's validation OID ballot

Is using a new OID a reasonable approach? There has been no push back.

There is an issue with the timing of implementation. It would great if it
was implemented in a year from the passing of the ballot as there is time to
implement and communicate that there is a new requirement. The timing was
proposed to be 6 months out, but since this was the end of the year, it was
moved out to 1 April 2019. There is a concern that giving 1 year might set a
new precedent. It was pointed out that most CAs implement early based on
their release cycles and do not wait until the deadline. It was suggested
that at least 9 months would be required, preferably a year as there needs
to be new processes and custom extensions from CA software providers. It
sounds like moving the deadline to 1 July 2019 would mitigate concerns.

 

5.	Specifying validation methods in CAA

Tim put out a paper in this issue, but we were not sure if the method has
been discussed with the validation Working Group. There is a concern as to
whether the validation methods should be part of an "Issue" record or being
there own record. This would not require an Issue record to be provided for
a single CA, but a record for validation could be provided for all CAs. The
ACME working group is also working on how to specify ACME methods. The WG
was not prepared to discss this issue today.

 

6.	Discuss new ballot: Fix method 10 to only allow secure methods (like
TLS APLN).  Remove method 9.

There is a solid draft of the new ALPN method in the IETF. It is proposed to
create a new method to use the ALPN method. This is a new method as it is a
substantial change to method 10. 

It was suggested that new methods should be narrow. As such ballot SC2 is
four methods.

There should be a new ballot to terminate methods 9 and 10 and create a new
method for ALPN. As no one is using method 9, we are not planning to improve
method 9. We may need to wait until the new ALPN method has been issued in
an RFC.

 

 

Thanks, Bruce.

 

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Tim
Hollebeek via Validation
Sent: July 13, 2018 11:53 AM
To: CA/Browser Forum Validation WG List <validation at cabforum.org
<mailto:validation at cabforum.org> >
Subject: [EXTERNAL][cabf_validation] Agenda

 

For next Thursday, sending early b/c I will be at IETF.

 

1.	IP address validation, method 6.
2.	CONTACT CAA tag and ballot SC2
3.	Validation Summit Method 3 ballot
4.	Wayne's validation OID ballot
5.	Specifying validation methods in CAA
6.	Discuss new ballot: Fix method 10 to only allow secure methods (like
TLS APLN).  Remove method 9.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180720/09958018/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180720/09958018/attachment-0001.p7s>