[cabf_validation] Minutes from the meeting of 19 July 2018

[Ryan Sleevi]

On Fri, Jul 20, 2018 at 1:22 PM Tim Hollebeek via Validation <
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> *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.
>
>    1. 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.
>    2. 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.
>    3. 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
>    <https://clicktime.symantec.com/a/1/a2DI3aG0X182jgQ7YMU8QiwnJxy83Vxnrp50nPSWQK8=?d=x8hNRNn_MZSmg90WqyjAKEPw73RO3x7ZKKwHv2SoKpp1cVZgyyrpbVGurHmZX3C8kUwFMpZPQrxwEyJsdClSP0VsSCAYPvfWfDeE8Dj7rrytYvL1pNUEwP_YXR4ERBcH5FdxseUBp66jRmZgeSP7p6_4aMt-gGjatKXnGW4fw3hiDcjbxYcacbIdnDK2cU3UQTa5BBSBWJhK_XtqguGvKPr82EvzL2hQ8jVSPWBOfgZuIRKYK80eb3sibfbwCI-Qkvac6qWnx8wZtUaBddenHZrLbqIKOdBqRFBfMI9_FIB2oh6vAZ0hGMs0JBDzVSHDVEwB7grCw2Epx6AkNZa7iy4wwpdWntnq_Hu2Sr1v2IYUB5Pev4_Lcw3J8GmWTmQZiqisY5SOJeXV9fA5MO8lOEzgNhA9xL-xfdvxLKaYmyfAm5k0YFSnvqhOHRGIOG51&u=http%3A%2F%2Fwww.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.
>
>
>
>    1. 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.
>
>
>
>    1. 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.
>
>
>
>    1. 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.
>
>
>
>    1. 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.
>
>
>
>    1. 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
> <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>
> *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
> https://cabforum.org/mailman/listinfo/validation
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180722/86f36069/attachment.html>