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

[Deb Cooley <[e-mail]>]

> 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.


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

> > 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
>
>