[cabf_validation] DRAFT Minutes of Meeting Held 3-Jan-2019

[Ryan Sleevi]

= Validation WG Minutes 3-Jan-2019 =
Validation Subcommittee of the Server Certificate Working Group
*Present:* Ben Wilson, Doug Beattie, Tim Hollebeek, Ryan Sleevi, Wendy Brown
*Agenda:* https://cabforum.org/pipermail/validation/2019-January/001174.html

== IP Validation Ballot (SC7) ==
Wayne’s taken up this ballot, after it languishing for a while, and the
discussion started with  points Ryan had raised on the document and on the
list.

=== Draft 3.2.2.5.1 ===
==== Validating Name Constraints ====
The first discussion about validating iPAddresses in nameConstraints and
subjectAltNames. Wayne wasn’t sure where that requirement came from; it
appears to have come from a F2F discussion and was drafted, but not clear
rationale. 7.1.5 requires that you put specific entries in the
excludedSubtrees, such as 0.0.0.0/0, so the question was whether or not you
needed to validate those entries. It sounds like removing the validation
requirement for excludedSubtrees is workable.

There was some discussion around the language about how nameConstraints are
not an exception to needing to validate iPAddresses. Ryan described a pro
and con - pro being that it can bring clarity, by emphasizing the point
that the presence of a nameConstraint doesn't absolve the CA of needing to
validate the IP appropriately, but the con that it could create confusion,
by not being parallel to the 3.2.2.4 requirements and thus give the
impression of being a special case. This may be something worth revisiting
as a clarification in a separate/future ballot, tackling both 3.2.2.4 and
3.2.2.5, while making it clear that DNS/IP validation should be
consistently performed.

Wendy asked to clarify the validation exclusion requirement, as it sounded
like an exception from validating the IP in a subscriber certificate if it
was present in the subordinate CA’s excludedSubtrees. Wayne clarified that
the exclusion for validation only applies to iPAddresses that are present
in the subordinate’s excludedSubtrees, and that the Subscriber certificate
would still have the IPs validated regardless. The necessity of this
exclusion comes from 7.2.5’s requirement to exclude certain entries in
excludedSubtrees.

Conclusion: Wayne suggested he’ll copy the language from 3.2.2.4 and then
modify it to be explicit that excludedSubtrees in a nameConstraints do not
need to be validated, as the Applicant won’t control them.

==== Well-known paths for domain names or IPs ====
3.2.2.5.1 borrowed language from 3.2.2.4.6, which has language about using
well-known paths for purposes of validating domain names or IP addresses.
There was language about “domain name or IP address” may be ambiguous for
validating IP addresses. Ryan discussed uncertainty about whether the
“domain name” was intentional - it depends on how the IANA registry is
created or established. Wayne wondered about the discussion for 3.2.2.4.6
was proposing to remove some of the language here regarding IANA, but Tim
clarified the discussion for 3.2.2.4.6 was about removing “or another path”
IANA method, and instead explicitly enumerating ones that are permitted,
such as acme-validation. No one precisely recalled the language
establishing the IANA registry for this, so agreed to revisit those
documents and propose changes to the language (or potentially keep it the
same), to avoid conflicting with that.

Conclusion: The decision was to revisit the IANA registry and align the
language, although if unclear, leave the “domain name or IP address”
language as-is. Further cleanups to this regarding "or another path" will
be tackled with a harmonized cleanup of 3.2.2.4.6 in a separate ballot.

=== Draft 3.2.2.5.2 ===
The current method allows the visual matching of organization; this has the
same issues with (now-deprecated) 3.2.2.4.1. The proposed change would be
to use the contact information from RIRs and issue a challenge, using
something similar to how 3.2.2.4.2 / .3 / .4 work for challenge/response.
That seemed desirable for folks, but there was some concern about whether
the RIRs would switch to omitting information in light of GDPR or other
regulatory changes. Tim suggested that the recently added TXT and CAA
methods for providing contact information, as future work. Ryan expressed
concern that this would be better suited to be had in the IETF as future
discussion, given the past concerns raised around ACME validation methods
for IP addresses and the use of reverse DNS or in-addr.arpa. Tim and Wayne
weren’t convinced that it would be necessary to change venue to have that
discussion, but all agreed to table for future discussion and to make sure
to consider such feedback.

Wayne expressed some concerns around using the constructed email method
(3.2.2.4.4), and there was agreement that this method wouldn’t be
necessary, and could be omitted.

Conclusion: Wayne will split 3.2.2.5.2 into two challenge-based methods,
using the phone or email information provided by the RIR. If the RIRs
switch to no longer providing this information, then the WG can explore
approaches similar to how this was addressed for DNS and WHOIS.

=== Draft 3.2.2.5.5 ===
Wayne wasn’t sure what to do with the TLS validation method, and some
discussion about whether or not this was being used by CAs. It shares
issues with 3.2.2.4.10, which is that as specified, it’s not necessarily
secure, but as Tim highlighted, the ACME TLS-ALPN method is not yet
finalized by IETF, and thus can’t be referenced. The question was whether
to leave it as-is, attempt to modify it to clarify some of the sharp edges,
or to remove it. The decision was that the best path forward is to remove
this method from the ballot. Folks that are using TLS-based methods can
speak up if it’s necessary, although there are so few certificates for IP
addresses it may not be. Wayne will follow-up with Let’s Encrypt to see
what issues removing this method may pose, and if there are issues, there
may be a path forward to introduce a more narrowly-scoped validation method.

Conclusion: 3.2.2.5.5 will be removed from the draft ballot, and Wayne will
follow-up with folks suspected of potentially using it to see if there is
any impact.

=== General Remarks ===
Doug raised the concern around validating IP addresses, and whether or not
the dynamic IP allocation was an issue. Are there issues with Subscribers
obtaining certificates for IPs and then being assigned new IPs. The
suggestion was that some methods - such as .1 and .5 - are particularly at
risk of being used for dynamic IP addresses, and whether lifetimes of 90
days or 2 years would be issues. Tim recalled the conversation at the
Validation Summit about the difficulty of determining static vs dynamic
addresses. Ryan echoed Doug’s point that, to some extent, the RIR
registrations are more stable and provide more information about the age of
their data than the other methods. He highlighted that this was similar to
the issues discussed with BygoneSSL, and the inclusion of stale data. There
was discussion about whether to try and scope this ballot to a minimal set,
such as just using the RIR data, keep it as is, or to expand the scope of
the ballot to try to address this.

Conclusion: The decision was that for now the group will maintain the
status quo, acknowledging it that this is a real issue, and look to address
this in the future, consistent with addressing BygoneSSL-type issues of
stale or changing information.

== Phone contact information via DNS ==
Tim asked Doug about how things were progressing on the 3.2.2.4.6 cleanup.
Doug clarified that his current focus, now that SC13 has passed, has been
on addressing a phone-based validation ballot to be equivalent. He hopes to
have that circulated soon.

== IANA CAA Registry Update ==
Ryan asked Tim about the status of SC13 and adding the new CAA property to
the IANA registry. Tim sent a note before the holidays to IANA, and is
waiting a bit longer before pushing again, given the holidays.

== BRs 3.2.2.4.6 ==
There was discussion about 3.2.2.4.6, continuing from the validation summit
discussion. There were some questions on three particular points on the
Method 6 that the WG wasn’t clear on. Tim was hoping Ryan remembered the
issues. Ryan said he’d try to page in the context and provide more details
for the next call, or we can otherwise ignore them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190103/b4a1b5cb/attachment.html>