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

From: Russ Housley <[email-masked]>
Date: Wed, 10 Nov 2021 17:06:45 -0500

We have already discussing the assignment of an object identifier for document signing.  An earlier call for document adoption lead to a lot of comments.  We had a presentation at IETF 112, and the authors reported that they have clarified what is meant by document signing, added a section for how to use the public key and certificate, addressed concerns about the extended key usage as a policy identifier, and expanded the security considerations.  Following the IETF 112 presentation, no one spoke against against adoption of this document.  This call is to see if there is rough consensus for the LAMPS WG to proceed with adoption of the revised document.

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 30 November 2021.

For the LAMPS WG Chairs,
Russ

---

From: Yoshiro YONEYA <[email-masked]>
Date: Thu, 11 Nov 2021 11:58:18 +0900

I support for WG adoption.

Yoshiro YONEYA

---

From: Corey Bonnell <[email-masked]>
Date: Thu, 11 Nov 2021 12:34:53 +0000

I support WG adoption of this document.

Thanks,
Corey

-----Original Message-----
From: Spasm <[email-masked]> On Behalf Of Russ Housley
Sent: Wednesday, November 10, 2021 5:07 PM
To: LAMPS WG <[email-masked]>
Subject: [lamps] Call for adoption for draft-ito-documentsigning-eku

We have already discussing the assignment of an object identifier for
document signing.  An earlier call for document adoption lead to a lot of
comments.  We had a presentation at IETF 112, and the authors reported that
they have clarified what is meant by document signing, added a section for
how to use the public key and certificate, addressed concerns about the
extended key usage as a policy identifier, and expanded the security
considerations.  Following the IETF 112 presentation, no one spoke against
against adoption of this document.  This call is to see if there is rough
consensus for the LAMPS WG to proceed with adoption of the revised document.

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 30 November 2021.

For the LAMPS WG Chairs,
Russ

_______________________________________________
Spasm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/spasm

---

From: "Brown, Wendy (10421)" <[email-masked]>
Date: Thu, 11 Nov 2021 14:09:54 +0000

I support the WG adoption of this document.

Thanks,
   wendy

-----Original Message-----
From: Russ Housley <[email-masked]>
Sent: Wednesday, November 10, 2021 5:07 PM
To: LAMPS WG <[email-masked]>
Subject: [lamps] Call for adoption for draft-ito-documentsigning-eku

For the LAMPS WG Chairs,
Russ

NOTICE: Protiviti is a global consulting and internal audit firm composed of experts specializing in risk and advisory services. Protiviti is not licensed or registered as a public accounting firm and does not issue opinions on financial statements or offer attestation services. This electronic mail message is intended exclusively for the individual or entity to which it is addressed. This message, together with any attachment, may contain confidential and privileged information. Any views, opinions or conclusions expressed in this message are those of the individual sender and do not necessarily reflect the views of Protiviti Inc. or its affiliates. Any unauthorized review, use, printing, copying, retention, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email message to the sender and delete all copies of this message. Thank you.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Nov 2021 17:12:24 +0100

Hi,

I just went through large part of this mail thread, the draft itself and
the presentation at IETF112.

I would at least like to raise some concerns about this EKU.

My absolute biggest worry is that we will initiate the old
non-repudiation debate in key usage where we desperately attempted to
distinguish between usage of keys for something similar to "document
signing" as apposed to using the key for signing to support
authentication or just data integrity.

In the wake of that discussion, many people started to debate how the
setting of this or that bit would affect the legal effect of such signature.

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.

The main difference is that if a certificate is declared as suitable for
a protocol, then it is easy to just deny that protocol action if the
identifier is not there. That has no implications rather than the
end-points fixing their certs to make the protocol work.

But if you receive a signed document, the harm is done and you can't go
back and ask the signer to sign with another cert. And the commitment is
done, and legally binding, whether there is a declaration of this type
or not.

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.

My biggest fear is that other standards groups in this area, like ETSI
ESI will start to update their signature validation procedures to check
for the presence of this EKU. I can hear the debate already.

To comments on the actual draft. The following text is problematic:

"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. If you
for example add a second EKU to the certificate, the certificate is
equally valid to be used with the other EKU. An EKU can therefore not
limit or restrict the use of the certificate for just this purpose.

Also, the definition of document signing is problematic:

In modern electronic services you cant isolate the signed document from
the process of creating, approving and signing content. This is because
what you see is what you sign is just a fairy tale. In practice you see
something, but you often sign some machine processable data that binds
the transaction/agreement to you, but it is not the visible content. It
is not even a document that you can make visible directly. This is the
case often when for example signing tax declarations. What you sign can
be an XML construct of codes and data that is key to the declaration,
but the XML data is only for machine processing. The data itself can be
visually presented, but it is a stretch to call that the signed
document. The world is simply not that neat and contained that we would
like it to be.

In the end. This EKU worries me. A lot.

/Stefan

---

From: Deb Cooley <[email-masked]>
Date: Fri, 26 Nov 2021 06:50:28 -0500

Apologies, it takes me a week or so to catch up w/ my normal work after an
IETF meeting.

I'm not in favor for separate keys/certs for different purposes.  The PKI I
support (US DOD) already has 3 keys/certs (ID, signing, encryption), adding
a 'you can only use this cert for one purpose' is a deal breaker.

I am in favor of distinguishing the difference between email signing, code
signing, and document signing.  In particular, I don't want to see code
signing overloaded.  I happy for that to make sense.  This mechanism?  or
another, I'm open to something that is simple and makes logical sense.

As for the nonrepudiation issues, that is a KU, correct?  And the KU
extension is classically marked as 'critical', whereas EKU is marked as
'not critical'.  One day, I hope and pray that the NR KU will no longer
exist in our (US DOD) certificates.

I would not be in favor of marking an EKU as critical, which theoretically
makes it easier?  But maybe not in Europe?

Deb Cooley
[email-masked]

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Fri, 26 Nov 2021 14:45:01 +0000

> I’m not in favor for separate keys/certs for different purposes.  The PKI I support (US DOD) already has 3 keys/certs

> (ID, signing, encryption), adding a 'you can only use this cert for one purpose' is a deal breaker.

I concur. 

> I am in favor of distinguishing the difference between email signing, code signing, and document signing.

> In particular, I don't want to see code signing overloaded.  I’m happy for that to make sense. 

If I understood correctly what you mean – I disagree.

In my practice, signing documents and (especially!) forms is as routine as signing emails (maybe, a LITTLE less frequent).

So, documents/forms get signed by the same key on the same hardware token as emails (Digital Signature key).

In practice it’s accomplished by having both (email protection and doc signing) EKUs included in the cert.

Your first point re. 3 keys present on a PIV token applies here.

> As for the nonrepudiation issues, that is a KU, correct? 

Yes.

> And the KU extension is classically marked as 'critical', whereas EKU is marked as 'not critical'.

Traditionally – yes, but I’ve seen EKU marked critical too (wrongly, IMHO).

> I would not be in favor of marking an EKU as critical, which theoretically makes it easier?  But maybe not in Europe?

I concur. EKU should NOT be marked Critical.

Thanks!

On Thu, Nov 11, 2021 at 11:12 AM Stefan Santesson <[email-masked]> wrote:

Hi,

/Stefan

---

From: Deb Cooley <[email-masked]>
Date: Sat, 27 Nov 2021 06:55:32 -0500

Deb:  I would be happy to have the EKU for document signing added to the
signature cert.  I would not agree to adding the code signing EKU to the
signature cert (we already disallow the use of the anyEKU for any of our
certificates for this reason).  It is this issue that I'm most concerned
about.

Misbehavior is plentiful in this space.  It is not a reason to stop issuing
certificates that are correct.

Deb

On Fri, Nov 26, 2021 at 9:45 AM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> > I’m not in favor for separate keys/certs for different purposes.  The
> PKI I support (US DOD) already has 3 keys/certs
>
> In my practice, signing documents and (especially!) forms is as routine as
> signing emails (maybe, a LITTLE less frequent).
>
> > I would not be in favor of marking an EKU as critical, which
> theoretically makes it easier?  But maybe not in Europe?
>
>
>