[cabfpub] CT discussion at CABF

[Ryan Sleevi]

On Thu, Feb 20, 2014 at 6:22 PM, Rick Andrews <Rick_Andrews at symantec.com>wrote:

> Ryan,
>
>
>
> Here are the suggestions I think I heard about how to reduce the
> uneasiness that some of us have. I hope others will chime too:
>

Rick,

I appreciate you providing this summary of discussion. However, I'd like to
take the time to address the feedback, as many of these items are not as
actionable as you suggest, and thus do not provide either clear exit
criteria or value in a way that we can show you that we have considered
them. I want to demonstrate to you that each of these things has been
considered, but without further input on your behalf, and on the behalf of
those you're summarizing, there's nothing more we can really do to help.

I want to avoid that situation, because it's clear you're unhappy, but it's
inevitable without more constructive feedback.

> -          Don’t rush into this, because we’re likely to make mistakes if
> we have to rush. Not just the CAs; there are a lot of moving parts here. I
> heard someone say “you can’t make fundamental changes to a complex trust
> system very quickly”.
>
While I can appreciate a sentiment of "Don't rush", this is a very vague
sentiment that is not actionably concrete. What, for example, constitutes a
rush?

An example of concrete and constructive feedback is "We can not make a
change faster than X months, for Y reason". This allows us to understand
what the lower bound for a change is. We can see it's clear that some CAs
feel that 2017 is "rushing" things, and I'm sure you could equally argue
that anything before 2025 is "Rushing" things.

In order to be constructive, it's necessary to demonstrate a clear way that
we can address it. Otherwise, any attempt we make can fall short, or be
argued as being the same fundamental problem.

Equally, we have an expectation that CAs participating within our root
store be able to respond to and address changes within a "reasonable" time.
In the same way that "rush" is vague, so is "reasonable". We've proposed a
date that we do believe, based on the feedback we've received from our
communications, as "reasonable". This may not be "reasonable" to all CAs
within our programs - but I don't believe we'll ever find a solution that
will make everyone happy, nor is that our specific goal.

We have reached out to each CA and provided a survey, exactly to determine
what the "moving parts" are and to collect the concerns individually, to
examine trends, and to see what represents an acceptable balance between
user security/improving the ecosystem and CA's concerns.


> -          Investigate the potential impact of EU privacy laws up front,
> because there seemed to be strong concern from the Europeans in the room
> that the privacy laws may be a problem.
>
I'm not sure why you mentioned this again, as we responded specifically and
clearly to this to the best of our ability during the F2F. There's nothing
more that we can provide you, and this does not lead to any sort of
satisfactory actionable outcome.

In order to be actionable or constructive, the "Europeans in the room" need
to demonstrate or provide something actionable, otherwise this is nothing
more than "Fear, Uncertainty, and Doubt", and that's not something we can
reasonably respond to.

To put it differently, in order to get us to (re-)consider our position on
this, it's incumbent upon those "concerned" to actually provide a concrete
concern. Otherwise, this is equivalent to continually saying "But have you
considered X" "Yes" "But have you REALLY considered X" "Yes" "What about
reconsidering X" "We have considered X". This is an endless loop with no
exit.


> -          Reach out to third-party software vendors. Many CAs use
> third-party software to generate and sign certificates and OCSP responses,
> and there is no clear understanding of whether those vendors know about CT
> and can make the changes available in time for CAs to upgrade.
>
As we mentioned, "We have".

If you feel this outreach has been insufficient, provide reasoning on what
"sufficient" constitutes for you. For example, is there a vendor you
believe is not taking this seriously and would impact your ability (or the
ability of your customers) to deploy CT? If so, this is the information we
were requesting repeatedly in the past, so I would encourage you to share
it now if you know.

If you know of examples of vendors who do not know or are not prepared for
CT, provide examples. As you can see, we're happily committed to both
helping vendors understand and, when and where possible, provide
implementation assistance and guidance.

If you believe that Vendor X cannot make changes in order for CAs to
upgrade, provide that information. This again is information requested in
the past, so it's good to have.

I can only say that any satisfactory conclusion of this is actually
incumbent on you to demonstrate a concern that can lead to an actionable
change on our end. We have assured you that this has been considered. I
don't know what more we can provide to satisfy you, and if you know of
counter examples, it's your responsibility to provide them so that we can
actually discuss this issue.


> -          Investigate the potential impact of other EU laws which may
> require such software to be certified before being put into operation.
> People seemed worried that because of this, there was no way they could
> comply in time.
>
Again, this is not necessarily constructive feedback because it suggests
that "some information exists, somewhere, that may change things". The only
way we can potentially obtain this information is from CAs - those who are
subject to such hypothetical laws - and receive such communications from
them.

We have reached out to all of the CAs that participate in our program. It's
the CA's responsibility to know their requirements for the areas that they
operate in, and we've requested (repeatedly) communications to the effect
as to whether there is such a thing.

If a CA fails to respond in a timely manner to such questions, then it's
not a failing on our part, nor is it something we can particularly remedy.
It also strikes as somewhat concerning if a CA waits until the last minute
to do so, both in terms of good faith and there ability to respond to
security incidents or future requests for information, so I would hope that
it would not lead to CA's waiting "until the last possible minute" to share
answers to questions that materially affect their ability to participate in
such programs.


> -          Improve communication. I heard that some of the CAs weren’t
> even aware of where to learn the details of things like precertificates. I
> don’t think the CT team has been withholding information, far from it, but
> some of the discussions have taken place on CABF lists, some on
> “therightkey” and now some will be on the trans list. And some information
> is at certificatetransparency.org. Perhaps it’s too scattered.
>
I'm not sure this is a problem that is actionable.

It has always been perfectly clear where the canonical source of
information about pre-certificates - RFC 6962. That is where all the
details exist.

If it's a question about how to make this information "more accessible",
well, that's exactly why we've taken discussion on the CABF lists, on the
IETF "therightkey", and now within the "trans" group. Different audiences,
different explanations, but a single canonical source - RFC 6962.

If it's a question about ensuring that all parties are known, well, as you
know, we've reached out to every CA that is within the program soliciting
feedback.

I feel like this again lacks a concrete, constructive feedback. It suggests
there's a problem, but provides no guidance on what would satisfy you to
believe this problem has been considered or addressed. I can only hope you
can provide an example of what you feel we might do to address this
concern, because absent that, it represents a general sort of "vague
feeling".

All the best,
Ryan

>
>
> -Rick
>
>
>
> *From:* public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] *On
> Behalf Of *Ryan Sleevi
> *Sent:* Thursday, February 20, 2014 11:34 AM
> *To:* Rick Andrews
> *Cc:* Dean Coclin; public at cabforum.org
> *Subject:* Re: [cabfpub] CT discussion at CABF
>
>
>
>
>
> On Thu, Feb 20, 2014 at 10:53 AM, Rick Andrews <Rick_Andrews at symantec.com>
> wrote:
>
> Ben L,
>
>
>
> Ryan wrapped up by saying that until now, you’ve heard only vague
> uneasiness from some CAs (my interpretation of what Ryan said; I can’t
> remember his exact words). Did you hear more specifics during this meeting,
> or would you like us to gather comments and present them to you?
>
>
>
> -Rick
>
>
>
>
>
> I think CAs have been quite clear they're uneasy, but have been vague in
> what can be done to reduce that unease. That is, there are both technical
> issues and timing issues. We'd certainly like to address any technical
> issues we can, and we'd like to understand the timing issues to see what
> can or should be done. This was certainly why we actively solicited
> feedback several months ago by contacting every CA in their program to
> gather such information.
>
>
>
> We welcome all constructive feedback. Unquestionably, the canonically best
> way to ensure that feedback is recognized and considered is by ensuring to
> send it to us (where "us" is myself and Ben Laurie, as you have with this
> email). That said, we're also happy to discuss and better understand the
> concerns within public forums such as the IETF -
> http://tools.ietf.org/wg/trans/ - or in visible forums such as the CA/B
> Forum.
>
>
>
> I have no doubt that the most spirited, robust, and meaningful discussions
> of the technical problems can be dealt with within the IETF Working Group.
> For the timing problems, that's ultimately something based on the Google
> Chrome policy, so we're happy to discuss those directly or publicly, at
> your discretion - since ultimately, no one can help you with your timing
> issues.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140220/0ef895cc/attachment-0001.html