Re: [lamps] Draft LAMPS Recharter

[Ryan Sleevi <[e-mail]>]

On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker <[e-mail]>
wrote:

> On Wed, May 2, 2018 at 10:19 PM, Ryan Sleevi <[e-mail]> wrote:
>
>> On Wed, May 2, 2018 at 5:20 PM Yoav Nir <[e-mail]> wrote:
>>
>>>
>>>
>>> On 3 May 2018, at 0:06, Ryan Sleevi <[e-mail]> wrote:
>>>
>>>
>>>
>>> On Wed, May 2, 2018 at 10:41 AM, Russ Housley <[e-mail]>
>>> wrote:
>>>
>>>> Based on the discussion in London and the "Potential Topics for LAMPS
>>>> Recharter" mail thread.  We propose the attached charter text.  Please
>>>> review and comment.
>>>>
>>>> Russ & Tim
>>>>
>>>> = = = = = = = = =
>>>>
>>>> 3. Specify the use of short-lived X.509 certificates for which no
>>>> revocation information is made available by the Certification Authority.
>>>> Short-lived certificates have a lifespan that is shorter than the time
>>>> needed to detect, report, and distribute revocation information, as a
>>>> result revoking them pointless.
>>>>
>>>
>>> I didn't see much discussion on the list in support for this, but
>>> apologies, I missed the discussion in SECDISPATCH when this draft was
>>> discussed.
>>>
>>> Is this being envisioned for the use in the PKI typically called the
>>> "Web PKI", or is this being seen as a draft for private use cases? I have
>>> read the draft, and do not feel this was clearly and unambiguously answered.
>>>
>>> I ask because, for various policy reasons, I would expect that
>>> undertaking this work may result in policies that explicitly prohibit it
>>> from being deployed on the Web PKI.
>>>
>>> As a practical matter, the draft acknowledges an alternative design
>>> (namely, OCSP stapling), but its two objections to this work do not hold.
>>> As a consequence, I have concerns about the motivations for and the
>>> alternatives considered, and thus don't think LAMPS needs to consider such
>>> work in scope at this time.
>>>
>>>
>>> Hi, Ryan.
>>>
>>> The main motivation for me is things other than the Web PKI. There is
>>> nothing in the draft that makes it not work for the Web PKI, but I would
>>> like to leave it to the group to decide whether the Web PKI is explicitly
>>> excluded.
>>>
>>> There is a short-term certificate document that *is* for the Web PKI. It
>>> is in the ACME working group.
>>> https://tools.ietf.org/html/draft-ietf-acme-star-03
>>>
>> <https://tools.ietf.org/html/draft-ietf-acme-star-03>
>>>
>>> Despite having some authors in common, the use cases are different.
>>>
>>
>> I’m curious to understand more of these use cases, as to understand the
>> presumed implementors for the running code. I’m guessing that, given the
>> goal just presented, these are going to be locally managed CAs and/or for
>> server-to-server mutual auth scenarios?
>>
>> My biggest qualm is that the draft seems predicated on two statements
>> about why existing technology is insufficient:
>> 1) OCSP Stapling requires servers to support Stapling
>> 2) Client certs cannot staple
>>
>> There doesn’t seem to be any explanation as to why #1 doesn’t equally
>> apply (if not moreso?) to this use case, given the need to replace the
>> certificates frequently due to their short lifetime. The efforts towards
>> ACME-STAR are illustrative of exactly that - a need for new management
>> capabilities.
>>
>> With regard to #2, I’m trying to understand how this compares to TLS1.3’s
>> restructuring of the Certificate message, which seems like it will have a
>> significantly broader adoption and a lower barrier to adoption, especially
>> in the case of client certs.
>>
>> While presented as specific examples, I think they more generally speak
>> to a lack of definition as to the problem space or audience within the
>> current draft, thus making it difficult to see how adoption,
>> implementation, or consensus will emerge. While personally skeptical of the
>> idea, I fully accept that there may be some non-WebPKI use cases for this
>> that could benefit from this work, but it seems like nailing those down and
>> identifying them should be encouraged as a prerequisite for adoption. In
>> particular, it seems like fleshing how this is meaningfully different in
>> use case or deployment from existing technologies such as OCSP Stapling
>> seems good, so as to prevent an unnecessarily proliferation of ways to
>> solve the same basic problem..
>>
>
> ​The reason to move to short term certs is simple and has nothing to do
> with insufficiency: It is simply more efficient.
>
> Once you automate the process of certificate management, the move to short
> lived certs is inevitable and obvious because then the server only needs to
> cope with a single data object rather than two equivalent data objects.
>
> With a long lived cert plus OCSP:
>
> * The server has to update its cert every X days and update its OCSP
> token, a different code path, every day.
> * The client has to process the cert and then process the OCSP token, each
> of which has a separate trust path.
>

To make sure I understand this claim: Is the view that adding yet another
method, which is not as expressive and with a host of trade offs, will
somehow payoff at some point in the future in which clients and servers no
longer have to implement or care about revocation data?

I would rather like to think “the spec is prettier if we do it this way” is
a poor justification for taking on work, so I was hoping a bit more
substance to a reply.

With a short lived cert:
>
> * The server has to update its cert every days.
> * The client has to process the cert.
>
> I do not understand where client certificates come into the argument.
> Obviously, the same approach may be applied to client certs but why would
> anyone bother when the browser UI for client auth is so utterly useless?
>

It’s unclear: you read the draft and are disagreeing with it, or did you
read me reply and weren’t aware I was referencing the draft? The mention of
browsers leads me to believe the latter, because the message I was replying
to identified this work was not for the Web PKI, but if the former, I’m
hoping to bring a bit more clarity to the position.

I don't want to get into business models but I will observe that my
> employer is making good money by adding back features some folk have dissed
> over the years.
>

I’m not sure how this furthers the discussion on the merits. Perhaps you
could elaborate how it fits with what we’re discussing? Or was this an
unrelated non sequitor you were calling out as such before making anyways?
I had a bit of trouble parsing.

>