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

[Deb Cooley <[e-mail]>]

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


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
>