> On May 19, 2017, at 7:45 AM, Ryan Sleevi <[email protected]> wrote:
>
>
>
> On Fri, May 19, 2017 at 10:27 AM, Peter Bowen <[email protected]
> <mailto:[email protected]>> wrote:
> The contention, from my view, is the definition of “data or document”. I
> think that all agree that a "utility bill, bank statement, credit card
> statement” provided by the customer in order for address verification is
> clearly a document and falls within the scope of this requirement. I also
> think all agree that data obtained from Companies House in the UK or the
> Division of Corporations of the State of Delaware about the existence of a
> company is clearly data that falls within the scope of this requirement.
> What is less clear or contentious is data obtained as a result of the
> validation process. For example, there is contention as to whether the data
> recorded by the CA that states that customer X controls p.com <http://p.com/>
> and example.aws is within the scope of the requirement. Additionally there
> is contention as to whether intermediate data is within the scope, such as
> data that shows that a Random Value was emailed to [email protected]
> <mailto:[email protected]> on 2017-02-24 at 15:52 UTC and the CA
> received a confirming response using the Random Value on 2017-02-24 at 17:14
> UTC.
>
> Yes, I agree, this is a summary of the dispute with respect to 4.2.1.
>
> Additionally I have seen some contention about the meaning of "The Random
> Value SHALL remain valid for use in a confirming response for no more than 30
> days from its creation” as found in ballot 169. As one of he authors of this
> language, I intended it to mean that the confirming response must have been
> received within 30 days of creation of the random value, but that the
> response itself could be reused as per 4.2.1. That is a CA could send a
> random value to the domain registrant on 2017-03-01 and received the
> confirming response on 2017-03-05 and then use that to issue a certificate
> for the domain on 2017-12-29. However I think I’ve heard someone suggest
> that the 30 days is how long you can reuse the confirming response which
> would mean it could not be used to issue on 2017-12-29. This is probably
> another place where it would be helpful to make super clear the expectation.
>
> To rephrase and confirm: As the author of that section, your understanding
> was that "The Random Value" constituted data obtained during validation,
> whose lifetime was limited to 30 days, rather than the fullness permitted
> under 4.2.1. You believed, however, that such usage was not in conflict with
> / a disruption to the existing practice under 3.2.2.4, in which the
> applicant, having confirmed the Random Value (and thus become a subscriber),
> was allowed to have multiple certificates issued using that previously
> completed verification, up to the limits permitted by 3.2.2.4.
>
> Or did you mean to suggest that the _first_ certificate issued was issued on
> 2017-12-29? If so, I think I would agree - if you do not use the confirming
> response by 2017-03-31 (30 days) to issue a certificate, then you would not
> be permitted to issue on 2017-12-29.
It was my intent and understanding that the 30 days had nothing to do with
4.2.1 or 3.2.2.4’s reuse requirements or allowances. We wanted to limit how
long a validation could be in a “pending” state. Therefore we added a
constraint on the delta between the time the confirmation was received and the
time the random value was generated. As long as the CA recorded when the
Random Value was created, recorded when the confirming response was received,
and those were not more than 30 days apart, the data could be reused months or
even years later.
You also seem to hint at another possible point of contention. There appears
to be a possible disagreement as to whether CAs have to follow a specific order
of processing for certificate requests. Notably, in
https://cabforum.org/pipermail/public/2017-April/010539.html
<https://cabforum.org/pipermail/public/2017-April/010539.html>, Ryan described
an possible order. However some CAs have described a different order, wherein
the customer initiates the request saying “we will be requesting a certificate
for example.com <http://example.com/>”, then the CA validates the domain, then
the customer submits the CSR and other required information necessary to
complete the request. The duration between the initial steps (through domain
validation) and the latter steps can be considerable — possibly months apart.
This is what some have called domain “pre-validation”. I think some have
suggested that the BRs don’t allow this alternative order of operations, but
I’m having a little trouble finding the specific cite. Do you, Ryan, or does
anyone else, think the order of operations described above is not valid?
> I do want to stress the flexibility and openness to consider interpretations
> so that we harmoniously align, despite the deep concerns about the security
> implications and the practices of some CAs, provided that we find an
> appropriate route to transparently quantify and assess the certificates, so
> that it is possible for relying parties to distinguish these issues.
I think our objective should be to get to a common understanding for all. The
BRs have historically been a consensus document, setting the minimum
requirements. CAs are welcome to go above and beyond. Where there is
contention, we should clarify, but the focus should not necessarily be on
raising the security bar, rather we should document where we are first, then
discuss raising it.
Thanks,
Peter
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
