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

While I understand that relying parties often do not/cannot validate fields
like certificate policies, EKUs and even KUs.

I do, however, think it is important to have an EKU between
id-kp-emailProtection and id-kp-codeSigning.  Clearly the code signing EKU
is inappropriate for document signature, as is the email protection EKU.
There is currently no general purpose EKU for 'document' signing - however
'document' is defined (and I don't believe boiling the ocean is required
here).

If there are CAs that are issuing code signing EKUs to enable document
signing, I do take issue with that practice, it should not be condoned.
Code signing is an extremely sensitive function and the use of keys to do
this must be limited.

If there are multiple private EKUs for document signing, I also take issue
with that practice.  They just create silos and are a barrier to
interoperability.

As such, I am in favor of this draft.  Providing the authors can pin down
the definition in quick order.  Charters can be changed, I don't find that
to be a barrier per se.

Deb Cooley
decoole@nsa.gov

On Wed, Jul 28, 2021 at 4:03 AM Eliot Lear <lear@lear.ch> wrote:

> How about the second paragraph:
>
> The LAMPS (Limited Additional Mechanisms for PKIX and SMIME) Working
> Group is chartered to make updates where there is a known constituency
> interested in real deployment and there is at least one sufficiently
> well specified approach to the update so that the working group can
> sensibly evaluate whether to adopt a proposal.
>
> Eliot
> On 28.07.21 03:32, Ryan Sleevi wrote:
>
>
>
> On Tue, Jul 27, 2021 at 6:31 PM Tomofumi Okubo <
> tomofumi.okubo@digicert.com> wrote:
>
>> The section will be referring to an existing RFC which is currently in
>> use.
>>
> I eagerly anticipate waiting to see which part of the charter [1] you’re
> proposing this new work item fits under.
>
> I cannot help but still be concerned, despite the stated belief, that is
> is a clear abrogation of the following language from the charter:
>
> The LAMPS WG may produce
> clarifications where needed, but the LAMPS WG shall not adopt
> anything beyond clarifications without rechartering.
>
> [1]
> https://datatracker.ietf.org/wg/lamps/about/
>
> _______________________________________________
> Spasm mailing listSpasm@ietf.orghttps://www.ietf.org/mailman/listinfo/spasm
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm
>