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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

> 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 <[e-mail]> wrote:

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

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