Re: [lamps] Proposed recharter text

[Ryan Sleevi <[e-mail]>]

On Mon, Feb 15, 2021 at 2:41 PM Tadahiko Ito <[e-mail]>
wrote:

> Hi Ryan
>
> As far as can I see, RFC5280 is based on the directory system which seems
> to be a general and ideal concept. As a result, 5280 seems to have become a
> general and ideal "profile" for certificates. Since 5280 is general and
> ideal (and too heavy), the actual implementations of PKI became a subset of
> RFC5280.
>
> I'm wondering if we can create some sort of a new Best Practice document
> which assumes more specific use cases (e.g. webPKI, PKI with trust list and
> without bridge, etc.) while making RFC5280 as an IS, which would fill in
> the gaps.
>
> (I am not sure if other forks will agree on such a document but ) doesn't
> it solve your concern?
>

I think, in the context of an Internet Standard, that approach wouldn’t
work unless we had sub-profiles that exercised all the bits that the
(other) sub-profiles excised. Otherwise, we’re still leaving unimplemented
dead weight in.

Don’t get me wrong, I think there is potential value in working to reflect
the rough consensus and running code, given the now three decades of X.509
experience, but my concern was and remains that the proposed charter
language doesn’t provide any guidance or prioritization on how to resolve
the questions necessary to advance to an Internet Standard, which we know
have been contentious and uninteroperbale.

We can:

A) accept it as-is, but lack an objective or reliable way to resolve these
disputes that (to this day) are unresolved among different communities

B) Try to find agreement on narrowing the community in the charter, such
that we have a rubric to evaluate options against

C) Attempt to progress to an Internet Standard, but not actually define the
interoperable profile that is robust and reliable. Instead, the goal is to
rather document the building blocks and semantics that communities are
expect to further profile down, including forbidding such features. The
distinction between A and C is largely that A attempts to exclude to “a
sensible, implemented set”, while C accepts all as valid for purposes of
documentation.

I don’t have strong opinions on these - they’re all a lot of work. And I am
certainly not trying to argue for an inherent superiority of Web PKI vs
other PKIs. My observation was and is merely that the “one size fits all”
attempt that 5280 captures/inherited from its ITU and IETF spec forbears
doesn’t really reflect the operational reality, in code or practice.  Such
dissonance means it would be a considerable work item to resolve, and we
should figure out early, during chartering, where the preferred path of the
WG is leaning to, so we can resolve concerns consistently and expeditiously.