Re: [lamps] Draft LAMPS Recharter

[Ryan Sleevi <[e-mail]>]

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

>
>
> On Thu, May 3, 2018 at 9:25 AM, Ryan Sleevi <[e-mail]> wrote:
>
>>
>> On Thu, May 3, 2018 at 7:47 AM Phillip Hallam-Baker <
>> [e-mail]> wrote:
>>
>>>
>>> ​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?
>>
>
> Short lived certs are exactly as expressive as long term plus OCSP with
> pre-generated validity tokens.
>
> While the intent of the original OCSP proposal (which I wrote the draft
> for and can thus speak with authority) was to enable insurance of
> individual transactions, I am not aware of any use of OCSP for that
> purpose. Nor do I expect any such use to arrive in the future as we
> subsequently developed the TAXI (Trust Assertion XML Infrastructure) for
> that purpose which is now known as SAML.
>
> 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.
>>
>
> ​Simpler is better. ​
>
> Changing practice in the browser world is certainly possible but has a
> long payback time as it takes quite a while for browsers to update.
>
> Instituting best practice for Web Services is a totally different matter
> as there are new services being deployed every day and those that exist are
> often kept up to date very aggressively.
>

While we may disagree as to whether this work is simpler - the draft I
think demonstrates that it's not, in practice, for any party involved
(relying party, CA, or service operator). However, I think there's
something to your point here which gets to the heart of whether LAMPS
should be undertaking this work. This is now the second message that you've
referenced the "browser world". While the initial replies suggested
non-browser/non-WebPKI case, which may be perfectly reasonable, I'm trying
to fully understand your position: Is it that this work is intended for the
browser case? If browsers explicitly prohibit the use of such work, or
reject implementation, does that undermine or devalue the work and
implementation experience? Because I do not see this being supported in
browsers, and I think it's extremely likely of being explicitly forbidden.

I highlight this in order to make sure there's consensus on what the draft
is for - since the draft itself leaves it ambiguous - and whether or not
there's a representative sample of implementors for that target use case.
The nature of this question is what plagued PKIX, and if we're trying to
ensure that LAMPS does not succumb to the overbroad, unadopted, zombie
effort that WGs can succumb to, then my $.02 we should make sure that the
goal and uses are as crisp as possible before adopting that work as a WG.

We can (and should) work out the "How" as a WG document, but the "Why"
seems like it should be addressed before adopting and incorporating into
the charter.