[cabf_validation] FW: FW: Draft Ballot SCXX: Improve Certificate Lifetimes

[Ryan Sleevi]

On Thu, Aug 1, 2019 at 3:27 PM Doug Beattie via Validation <
validation at cabforum.org> wrote:

>
>
> I replied to a couple of points below, but to summarize this discussions:
>
>    1. The Proposer/endorsers will provide a good write up of why these
>    changes are needed and why they are needed in the specified timeframe
>
> For sure! To be clear, this was always on the table and the todo list :)

Because there seemed to be greater interest in looking at specific text,
rather than reasoning, I wanted to try and get that part in front of folks,
which is what I was trying to do on this thread. I'm 100% in agreement that
any ballot needs to be clear about the why, as it goes to the ballot stage,
and as folks look to co-endorse, we could collaborate and clarify those
reasons with the actual ballot text.


>    1. Shortening the certificate validity and domain-re-use together is
>    necessary to meet the intended goals
>    2. The reuse period for Organizational data is open for discussion and
>    doesn’t necessarily need to be the same as the validity period
>
> Right. I think that without shortening the organizational data, the value
provided to relying parties is going to vary based on how the information
was validated. That is, if the maximum is too great, there may not be any
value in displaying it, and may be harmful to do so. But that's really a
per-product/per-browser decision, and I'm fully happy to treat those
orthogonally. In the worst case, if the reuse period was too great,
browsers could always gate the display/use of that information to only CAs
which they knew validated under the more frequent timescale, such as by
separate audits to establish that. This would allow the BR audits to have
the more general, less secure upper bound, but the benefit of not requiring
CAs to do any changes to avoid qualified audits nor require all UAs to
adopt the same policies simultaneously. The validity period and domain
validation parts, however, are far more critical and impactful to user
security, which is why I'm totally happy to treat them separate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20190801/3348a8bc/attachment.html>