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

[Ryan Sleevi <[e-mail]>]

I have read the draft, as well the meeting materials from IETF 111 [1], and
I do not support adoption.

Explicitly, I do not believe it furthers its stated goal of promoting
interoperability.

The existing set of IANA-assigned EKUs [2] have a practical
correspondence to IETF-defined protocols:
* id-kp-serverAuth corresponds to the TLS protocol (RFC 8446), typically
combined with HTTP (RFC 7231) as further expanded by RFC 6125
* id-kp-OCSPSigning corresponds to the OCSP protocol (RFC 6960)
* id-kp-timeStamping corresponds to the use of the Time Stamp Protocol (RFC
3161)
* id-kp-emailProtection corresponds to the use of CMS (RFC 5652) as used by
S/MIME (RFC 8551)

The current draft [3] fails to properly justify the need for an
IANA-defined EKU within introduction, and fails to define any practical
protocol that this key usage should be bound to. It intentionally and
explicitly leaves it ambiguous on the appropriateness or inappropriateness
of its use, and thus fails to provide any interoperable value. The draft
suggests that there is value in assigning from the IANA arc, but fails to
provide any practical or technical justification to that effect.

These are, I believe, blockers towards the adoption of the work: Without a
clear justification that both informs the goal and the potential scope of
work, I do not believe the draft should be adopted as a work item for the
WG.

At its core, the value provided for this EKU is to indicate a
locally-interpreted meaning which lacks interoperability, namely:
"Inclusion of this KeyPurposeId in a certificate indicates that the use of
any Subject names in the certificate is restricted to use by a document
signing service or a software". That is, it seeks to assign semantic
meaning to an area subject to local policy (e.g. a naming authority). Using
a policy OID appropriate for the local naming authority is entirely
appropriate and suitable, but a generic OID to indicate a certificate is
subject to "a" naming authority is not valuable in and of itself.

[1]
https://datatracker.ietf.org/meeting/111/materials/slides-111-lamps-sessa-general-purpose-eku-for-document-signing-00
[2]
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3
[3] https://datatracker.ietf.org/doc/html/draft-ito-documentsigning-eku-01

On Mon, Jul 26, 2021 at 6:13 PM Russ Housley <[e-mail]> wrote:

> We have already discussing the assignment of an object identifier for
> document signing, and we had a presentation at IETF 111.  Following the
> IETF 111 presentation, no one spoke against against adoption of this work.
> This call is to see if there is rough consensus for the LAMPS WG to proceed
> with this work.
>
> Please send your reply about whether you support adopting
> draft-ito-documentsigning-eku as a WG document.  Please voice your support
> or raise concerns by 14 August 2021.
>
> For the LAMPS WG Chairs,
> Russ
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm
>