[cabf_validation] Minutes from the meeting of 19 July 2018

Tue Jul 24 07:49:35 MST 2018

They’re redirects in the sense of sending to you to a new page, and they’re in fact the most common kind of redirect.  And they are mentioned on the Wikipedia page for URL redirection (https://en.wikipedia.org/wiki/URL_redirection), so not everyone shares your view.  They were discussed the last time we discussed this topic on the VWG (in terms of making it explicit that they shouldn’t be parsed or followed).

The fact that different people mean different things by the term is one of the reasons we need to clarify what exactly is and isn’t allowed.

-Tim

From: Ryan Sleevi <sleevi at google.com> 
Sent: Tuesday, July 24, 2018 5:46 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org>; Bruce Morton <Bruce.Morton at entrustdatacard.com>
Subject: Re: [cabf_validation] Minutes from the meeting of 19 July 2018

Those aren't redirects in any sense, though.

On Mon, Jul 23, 2018 at 3:59 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

I don’t disagree with you that there’s some important complexities to consider with respect to 302s.  But there are even more complexities for redirects that use page content, like meta refresh or javascript redirects.

-Tim

From: Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > 
Sent: Sunday, July 22, 2018 11:30 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Cc: Bruce Morton <Bruce.Morton at entrustdatacard.com <mailto:Bruce.Morton at entrustdatacard.com> >
Subject: Re: [cabf_validation] Minutes from the meeting of 19 July 2018

On Fri, Jul 20, 2018 at 1:22 PM Tim Hollebeek via Validation <validation at cabforum.org <mailto:validation at cabforum.org> > wrote:

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.

Hi Tim,

I wish I shared your optimism that 302 was the simplest, but as someone who maintains an HTTP stack, it's not always the case.

Consider the situation with a server emitting multiple Location headers as an example of complexity. Alternatively, open redirects are an issue (although hopefully eliminated by /.well-known/), but for servers that do blatent redirects that don't preserve the URL (e.g. "http://example.com/.well-known/thing" or "http://example.com/anything" always redirects to "http://example.net/new_name_who_dis"), there are also implications to consider.

To some extent, we want to say "the CA uses a good HTTP stack" - but it's worth thinking about things more carefully and concretely, treating this as a technical standard and assuming nothing is obvious, than hoping it's all just simple.

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?

You're validating the domain owner has authorized the certificate. While they've delegated that authorization, that's no different than a domain holder that uses a CDN to provision their certificates, or a domain holder that has an IT management company handle their certificates.

If CAs are worried about third-parties being involved in the certificate issuance process, then I'd be curious to know whether they plan to take steps to forbid resellers and partners as well.

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 <mailto: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 <mailto: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 <http://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.

_______________________________________________
Validation mailing list
Validation at cabforum.org <mailto:Validation at cabforum.org> 
https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180724/dee5dc44/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/20180724/dee5dc44/attachment-0001.p7s>