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

[Tadahiko Ito <[e-mail]>]

Hi Stefan,

Thanks for your comments.

> I think that the only thing we could agree on in the end was that it
> probably was a huge mistake to try to bind a key to a purpose, as
> opposed to binding the key to a particular protocol

While binding each and every protocol does have challenges, as you seen in
the previous discussions, we are not opposed to that idea. For instance, in
a automated authentication system, it is effective to assign an EKU to a
protocol.
However, we recognize that there are some use cases where assigning a EKU
per protocol is not realistic. An example is with a PIV card which has
limited amount of slots which would not scale if there are too many EKUs
per protocol which equates to many keys on the card. This is one of the
cases we had in mind for having a general document signing EKU.

I think it is rational to bind EKUs to specific protocols for many use
cases.
However, as such practices become more widely use, some difficult-to-bind
applications would appear, and we need some choices for those application.
(I believe it is similar to basket clause in the legal systems, and common
approach to deal with classification.)
For example, as it was mentioned on slide 3 of IETF111's presentation and
also on the I-D, we have introduced, or rather, allowed a bad practice of
using email protection or code sign EKU for document signing to infest.
<
https://datatracker.ietf.org/meeting/111/materials/slides-111-lamps-sessa-general-purpose-eku-for-document-signing-00
>
We believe that our approach is a rational and valid way to solve this
problem by means other than making 5280bis.

> So my question is basically. What are the signer and the verifier
> supposed to do based on seeing or not seeing this EKU in a cert. That is
> not at all clear to me.

We believe beyond what we described in section 4 is something dependent on
the policy which the relying party or the relaying party software follows.
We gave enough room to accommodate myriads of policies hence, the name
“general”.

In this draft, we focused on describing the mechanism as much as possible
and tried to be policy neutral.
That should be defined by the policy body (if applicable). Also please note
that not all of the document signing schemes have governing policy bodies,
for example, the document signing in RFC8358.

> "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."
>This is not compatible with the function of the EKU extension.

We received the same comment regarding this part and will be fixed in the
next revision.
We believe this does not affect the WG adoption.

Thanks,

Tadahiko