Re: [lamps] Draft LAMPS Recharter

[Ryan Sleevi <[e-mail]>]

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.