[cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

[Ryan Sleevi]

On Fri, Aug 10, 2018 at 3:39 PM Tim Shirley <TShirley at trustwave.com> wrote:

> That is a disconnect then from what was discussed in the validation
> working group, unless I’m misunderstanding.  The minutes cited an example
> scenario where, upon determining that a domain validation method was
> insufficient, the domain is revalidated using a different method but the
> certificate itself is not replaced.  If a relying party was looking at this
> data in the certificate to make a trust decision, then that necessitates
> replacing the certificate for it to continue to be trusted.
>

Right, and I responded to that discussion in
https://cabforum.org/pipermail/validation/2018-August/001017.html


> I’m not trying to resist the transparency; I don’t think James or Tim are
> either.  I’d argue the metadata approach actually provides much greater
> transparency.  For example, the metadata approach might record, for a
> DNS-based validation, what DNS server was queried and when.  Now say there
> is a DNS hijacking discovered for a certain subnet / period of time.
> You’re in a much better position to be able to determine which certificates
> are affected than you are when only the method is encoded into the
> certificate.  Given the discussion in the validation working group
> concluding that this shouldn’t be used for real-time decisions, this seemed
> an opportunity to be able to provide that greater transparency.
>

I fail to see the conversation as concluded, by any means. I'm still
waiting for meaningful discussion about the tradeoffs there. There is real
value in making it used for real-time decisions that directly protects
users.

I think it's also a bit misguided to say it's transparent - in that, unlike
the certificate itself, the expressions of this information in every other
form is mutable or deniable by the CA. Even a notion such as suggested by
DigiCert, where DigiCert would run a 'transparency log', ignores or leaves
unaddressed the challenges with assuring the immutability of that log.

I captured the issues with transparency logs in
https://cabforum.org/pipermail/validation/2018-August/001014.html .

In any event, I disagree with the framing that the decision has been
'concluded'. We've seen two CA members express views, and one browser
member not take a position, and one browser member express clear support of
including. I would say the conversation is very much ongoing :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180810/dfd84a1b/attachment.html>