Re: [lamps] Draft LAMPS Recharter

[Phillip Hallam-Baker <[e-mail]>]

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.


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?


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.