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

[Tim Shirley]

Sorry, “concluding” was a poor choice of words.  I didn’t mean to suggest the conversation was over; only that that was apparently the consensus from that particular call.  I’m just trying to get clarity of what I think I’m hearing from you: that you DO envision this information being used to make real-time trust decisions.

And I think we’re just using different definitions of transparency, rather than it being misguided.  I was simply speaking of sharing more information openly, whereas you’re adding to that definition evidence of immutability.  In terms of openness, the metadata approach provides greater potential for transparency than would be practical in a certificate.  And I see no reason it couldn’t also be made provably immutable, though certainly with more effort required to get there.

Tim Shirley
Software Architect
t: +1 412.395.2234

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

Recognized by industry analysts as a leader in managed security services<https://www.trustwave.com/Company/About-Us/Accolades/>.


From: "sleevi at google.com" <sleevi at google.com>
Date: Friday, August 10, 2018 at 3:47 PM
To: Tim Shirley <TShirley at trustwave.com>
Cc: "validation at cabforum.org" <validation at cabforum.org>, Tim Hollebeek <tim.hollebeek at digicert.com>
Subject: Re: [cabf_validation] [EXTERNAL]Re: Ballot Proposal: Validation Method in certificatePolicies

On Fri, Aug 10, 2018 at 3:39 PM Tim Shirley <TShirley at trustwave.com<mailto: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<https://scanmail.trustwave.com/?c=4062&d=1evt293NepvaUaPluJeRm7lrZv2tjfxkGooa6XpmEg&s=5&u=https%3a%2f%2fcabforum%2eorg%2fpipermail%2fvalidation%2f2018-August%2f001017%2ehtml>

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<https://scanmail.trustwave.com/?c=4062&d=1evt293NepvaUaPluJeRm7lrZv2tjfxkGoMc4yk6Eg&s=5&u=https%3a%2f%2fcabforum%2eorg%2fpipermail%2fvalidation%2f2018-August%2f001014%2ehtml> .

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/e6ebe988/attachment-0001.html>