[cabfpub] Pre-ballot for Ballot 190

[Ryan Sleevi]

There is confusing language - which can be ambiguous - and then language
that may be actively detrimental (that is, the plain reading is a normative
change).

Consider 3.2.2.4.1 as an example. It includes the following draft text:
"Note: Once the FQDN has been validated using this method, the CA MAY also
issue Certificates for FQDNs for higher level domain levels that end in the
validated FQDN. This method is suitable for validating Wildcard Domain
Names."

This has a few issues. First, the ability to validate an FQDN by pruning
one or more labels is already addressed by the definition of "Authorization
Domain Name", which is the domain used for authorization. It's unclear
whether this Note is offering an alternative definition (e.g. it is not
describing the ADN process) or whether it's meant to be a non-normative
statement of ADNs.

In further considering the language, note the specific choice of "higher
level domain levels". DNS is a hierarchy, working from a 'top' to 'bottom'.
This is why we say "top level domain" (or TLD). The scope of authority
flows downwards, not upwards. Thus, the choice of "higher level domain
levels" is ambiguous - is it meant to say lower-level, or subordinate,
domain levels? As it stands, there can either be no "higher level domain
levels that end in the validated FQDN" (that is, if I validated google.com,
the higher level domain is .com), or it is meant to redescribe the process
of "Authorization Domain Name", in which I request "www.google.com", I use "
google.com" as the Authorization Domain Name, and thus, the ADN ==
"validated FQDN". However, this conflicts with the plain reading earlier in
the sentence.

Similarly, the statement "This method is suitable for validating Wildcard
Domain Names" is either redundant (by virtue of ADNs describing how to
validate), or it's redefining (defining a mechanism alternative to ADNs)

My concrete suggestion: Remove the entire "Note" section to avoid the
hopefully unintentional ambiguity. This same probably, notably, persists
through every "Note" being introduced - in the effort of trying to
introduce clarity, it actually introduces conflicting language that either
disagrees with the definition of ADN, or redefines it.


With respect to 3.2.2.4.4, it's worth calling out the ambiguity derived
from a plurality disagreement that isn't present in 3.2.2.4.2. That is,
3.2.2.4.4 notes "provided that its entire contents and recipient SHALL
remain unchanged", but notes that it may be sent to one or more addresses
(in the opening sentence). 3.2.2.2.4.2 resolves this ambiguity by noting
that "provided that the communication's entire contents and recipient(s)
remain unchanged" - that is, note the plurality "(s)" that provides
stronger guidance. A misreading of this, but one which is technically
correct, would be that I could send a mail to "webmaster at example.com", but
then also add "ryan at example.com" in the re-sent message as a CC or BCC,
leaving the TO line unmodified - as the recipient (webmaster at example.com)
remains the same. (Unless we want to haggle over SMTP semantics, despite
not stating SMTP be used)

3.2.2.4.7 also presents an interesting challenge - whether or not it's
ambiguous language or intentional. It notes that the Random Value SHALL not
be used after "(ii) if the Applicant submitted the Certificate request, the
timeframe permitted for reuse of validated information relevant to the
Certificate". Consider the following, and determine whether or not this is
desired, where T= the particular day.
T=0: Applicant submits request. CA generates Random Value, Applicant puts
it in the TXT. Certificate 0 is created, expires T=1188 (39 months).
T=1095: Applicant submits another certificate request. CA is allowed to
reused Random Value (as it's within the 4.2.1 window for overall time),
thus constituting a newly completed validation. (1095 = 3 years / 36
months). Certificate 1 is created, expires T=1918 (1095 + 27 months)
T=1825: Applicant submits another certificate request. CA is allowed to
reuse previously completed validation (as its within the 4.2.1 for
completed validations), thus issuing a 27 month certificate (1825 = 5 years
/ 60 months). Certificate 2 is created, expires T=2648 (1825 + 27 months).

As currently worded, 3.2.2.4.7 allows you to use a single random value -
provided the domain holder does not remove the TXT record between T=0 and
T=1188 - for approximately 2648 days (or more), or roughly over seven years.

Given the proposed modifications to 4.2.1, simply removing (ii) entirely
would suffice, and ensure the Random Value is only used for 30 days, but
the completed validation is usable for the time permitted by 4.2.1


Notably, in the process of reviewing this text, a certain asymmetry stood
out with our existing adoption, which likely represents a critical security
flaw that should be remediated as soon as possible, or considered in the
context of the new methods being introduced.

3.2.2.4.10 - This method does NOT restrict the Random Value duration, as
done so in 3.2.2.4.7 or 3.2.2.4.2. This could, for example, allow
'perpetual' authentication. A good example of this would be a CA issuing a
certificate for 'example.com'. As 3.2.2.4.10 does NOT require that the
Random Value be unique to the certificate request (as done by 3.2.2.4.7 or
3.2.2.4.2), the CA could argue that the serial number constitutes a Random
Value that was pre-generated. In this method, a CA could determine that any
request for 'example.com' is authorized, provided that 'example.com'
continues to serve the same certificate. While I can understand that may be
ideal for some CAs looking to validate a subscriber once, and never having
to do so again, it opens up an ambiguity that represents a critical
security flaw - there's no binding that the Applicant is the same (or that
the public key is the same).

That is, consider the following: I, the true domain holder, approach CA Foo
to issue a certificate for "example.com", which they duly issue after
validating (using some means other than 3.2.2.4.10). I install this
certificate on my domain. At some time later, Gerv, the unauthorized
requester, approaches CA Foo, with a new public key, and requests a
certificate for "example.com". CA Foo attempts to validate using
3.2.2.4.10, and sees that a certificate they previously issued is on
example.com. They then assert that the serial number in that certificate
constitutes a "Random Value", thus authorizing Gerv's request, and issuing
a certificate for example.com to Gerv, with a private key Gerv controls.
This would be fully permitted under 3.2.2.4.10.

Given 3.2.2.4.2 and 3.2.2.4.7 are 'new' to this ballot, we need to decide
whether or not it was intentional to require those two use a Random Value
"unique to the Certificate request" and whether it should be permitted to
remain valid in a confirming response for longer than 30 days from its
creation. I would argue that 3.2.2.4.2 and 3.2.2.4.7 do it correctly, and
3.2.2.4.10 is flawed in its security, which is only apparent through the
comparison.


Finally, in considering the proposed changes to 4.2.1, it's worth noting
that the provision beginning "After the change to any validation method" -
as worded, this would permit CAs to continue to use the "Any other method"
of validation for another three years. Is it intentional that, after nearly
3 years of discussion, CAs are still permitted to use insecure validations?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170629/062c0281/attachment-0003.html>