Re: [lamps] Paul Wouters' Yes on draft-ietf-lamps-documentsigning-eku-05: (with COMMENT)

[Tadahiko Ito <[e-mail]>]

Hi Paul

Apologies for delay on my response.

Following are our comments and proposals.

Regards Tadahiko

> ### humans
>
>   The term "Document Signing" in this document refers to digitally
>   signing contents that are consumed by people.  To be more precise,
>   contents are intended to be shown to a person with printable or
>   displayable form by means of services or software, rather than
>   processed by machines.
>
> Is there a reason to only include human readers and not machines? Why not
> leave it to users to decide how to use this?

It is common practice that many (machine-proseccing) protocols have their
own keyPurposeId, and some policies requires use of a specific keyPurposeId
for that protocol
(we learned form problems on use of anyExtendedKeyUsage). I also support
use of a protocol-specific keyPurposeId for machine-processing protocol.
(Machines can control arbitrary number of keys automatically, so I believe
it is sound for machines to use protocol-specific key (and certificate with
protocol specific keyPurposeId)).

In the other hand, human can only control small number of keys (e.g., some
IC cards only have 3 slots, human can confuse management of card and PIN,
etc...).
So, if we require a human to use (and manage) protocol specific key (with
protocol specific keyPurposeId), that person would face bigger operational
risks.
Some developer use id-kp-emailProtection etc. as a general keyPurposeId for
human interacting protocol to avoid that risk, but it is not good practice
as we wrote on the draft.
To avoid that issue, we need general keyPurposeId for human use.

That is reason we purposely restricted this to human readers from the very
start.

> ### key usage vs KU
>
>   The EKU extension can be used in conjunction with the key usage
extension
>
> Would it make sense to call that the KU extension, or key usage (KU)
extension

It would, but interestingly enough we have never heard any one every refer
to it as the KU extension.
Two characters might be too short to identify, or "key usage" seems short
enough not to shorten...
We would like to leave that.

> ### Section 4 humans again
>
>   The signed contents of Internet-Drafts are primarily intended to be
>   consumed by people.
>
> ### RFCs is people?
>
> What is this "signed contents of Internet-Drafts" ? Should that be "signed
> contents of Documents" ?

Lars caught this too. Previously, there was a paragraph that provided
motivations - namely [RFC8358] - signing I-Ds. We changed this to
“documents” in:
https://github.com/lamps-wg/documentsigning-eku/pull/20

> ### single example?
>
>   When a single application has the capability to process various data
>   formats, the software may choose to make the excluded and permitted
>   decisions separately in accordance with the format it is handling
>   (e.g. text, pdf, etc).
>
> Why is this text in the document? It seems kinda out of scope.

I believe this is relevant with above "human cannot control arbitrary
number of key " issue.
If human were facing with software, which can handle several (protocol and)
data format, it is quite demanding for that person to choose
dataformat-specific-key.
That sentence is talking about that.
We believe it is more clear with other changes on this email and above
/pull/20.

> ### Section 6 allows squatting?
>
>   This general
>   document signing KeyPurposeId may be used as a stop-gap for those
>   that intend to define town KeyPurposeIds
>
> It seems weird for this document to say "this is for document signing,
but hey
> go squat on this value for other uses if that's convenient".

This was not our intent. I think a couple of words are missing:
s/own KeyPurposeIds/own document signing KeyPurposeId.

> ## NITS
>
> ### Section 1
>
> [RFC5280]  is a broken link

Thanks.  we will fix that.
("RFC5280" on the abstract of the MD file needed to have space between RFC
and 5280... )

> I can't parse: the usage can easily become out of control.

We will fix as below.
s/become out of control/become difficult to control

> weird use of "-" in:  use. - If the

We will drop the “-"

> Paragraph 3 in Section 1 is in its entirety hard to parse.

That paragraph is talking about somebody appropriating (or
misappropriating) an existing KeyPurposeId and what can go wrong if that
happens.
Note that a couple of companies already have document signing EKUs.

how about following sentence.

OLD:
There is no issue if the vendor-defined KeyPurposeIds are used in a PKI
governed by the vendor or a set of specific group of vendors. However, if
the KeyPurposeId is used outside of vendor governance, the usage can easily
become out of control. For instance, when the end user encounters
certificates with vendor-defined KeyPurposeIds, they might want to ask that
vendor about use of the certificate. However, if those certificates were
not governed by the KeyPurposeIds owner but by another vendor, the vender
who own the KeyPurposeIds may not able to control use, or even do not know
about the use. - If the issuance of the cert is not under the control of
the KeyPurposeIds owner, it is hard to estimate the impact of change to
made on the KeyPurposeId. Changes related to KeyPurposeIds possibly make
negative impacts that some group of people do not tolerate, and it could
become a migration agility issue.

NEW:
Vendor-defined KeyPurposeIds that are used in a PKI governed by the vendor
or a group of vendors poses no interoperability concern. Appropriating, or
misappropriating as the case may be, KeyPurposeIDs for use outside of their
originally intended vendor or group of vendors controlled environment can
introduce problems, the impact of which is difficult to determine.

> ### Section 3
>
> [RFC5280] is a broken link

Thanks. we will fix that.
("RFC5280" on the abstract of the MD file needed to have space between RFC
and 5280...)