Re: [lamps] Call for adoption for draft-ito-documentsigning-eku

[Russ Housley <[e-mail]>]

DKG:

I suppose it does allow many OIDs to be assigned.  I was trying to come up with a way to allow simple documents that assign an OID and achieve WG consensus to move along without too much administrative overhead.

All of the other approaches that I considered allowed the assignment of a single OID for one specific purpose.  I'm open to alternatives.

Russ

> On Aug 17, 2021, at 2:08 PM, Michael Richardson <[e-mail]> wrote:
> 
> Daniel Kahn Gillmor <[e-mail]> wrote:
>>> Many people have spoken in support of this document, and two have
>>> spoken against.
>>> 
>>> If it is to be adopted, an addition to the chart is needed:
>>> 
>>> The LAMPS WG will support new definitions of objects registered in the
>>> following IANA registries: SMI Security for S/MIME Mail Security
>>> (1.2.840.113549.1.9.16) and SMI Security for PKIX (1.3.6.1.5.5.7).
>>> 
>>> What do people think about this approach?
> 
>> The above strikes me as an extremely broad change to the charter,
>> permitting apparently arbitrary work within LAMPS as long as it manages
>> to touch those IANA registries.
> 
>> Both objectors to and supporters of the proposed document-signing work
>> appear to be concerned about proliferation of Extended Key Usage (EKU)
>> OIDs with semantics that are ill-defined enough to produce interop
>> failures, and to potentially increase the costs of certificate
>> management.
> 
> Being charted to be able to make a billion EKUs doesn't mean that the WG or
> the IESG will sign off on doing that.
> 
>> But opening the charter wide to encompass any work that happens to
>> touch one of the arcs mentioned above seems like writing a blank check.
>> Maybe that's what the WG wants to do, but it doesn't look like it will
>> help the WG stay focused.
> 
> I want to avoid stopping work every 4 weeks to revise the charter.
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
> 
>