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

[Eliot Lear <[e-mail]>]

Hi,

We should separate two different arguments you are making.

 1. Whether the IETF is the right forum to allocate an OID in one of its
    own arcs
 2. Whether the document is clear enough to be used properly.

Taken in reverse order, the document needs to be clear as to when this 
particular EKU MUST and MUST NOT be used.  I agree with Ryan Sleevi that 
the document could do a better job in explaining this, but for a number 
of reasons, I still support.  In the IETF we ourselves have overloaded 
id-kp-emailProtection at least in part because the other alternative – 
id-kp-codeSigning – is more expensive to deploy.  It is simply *not* 
practical to support gazillions of EKUs.  CAs can barely handle three.  
Adding one more will be challenging enough, which is why I asked if 
there was an intent to deploy by CAs, and the answer was, “yes”.

On (1), RFC 5280 was written prior to the requirement for explicit IANA 
policies, but there is no basis to believe that a protocol is required 
to establish an EKU.  What is required is understanding of the lack of 
semantic claims over such a generic signature.

Finally, we do not want a requirement for more specific EKUs (or any 
other extension) to become a barrier to deployment.  In the end that 
just makes it less practical to use certificates.  If you're reading 
this as, “the CAs can't/won't keep up”, then you've understood my message.

Eliot


On 27.07.21 03:21, Ryan Sleevi wrote:
> I have read the draft, as well the meeting materials from IETF 111 
> [1], and I do not support adoption.
>
> Explicitly, I do not believe it furthers its stated goal of promoting 
> interoperability.
>
> The existing set of IANA-assigned EKUs [2] have a practical 
> correspondence to IETF-defined protocols:
> * id-kp-serverAuth corresponds to the TLS protocol (RFC 8446), 
> typically combined with HTTP (RFC 7231) as further expanded by RFC 6125
> * id-kp-OCSPSigning corresponds to the OCSP protocol (RFC 6960)
> * id-kp-timeStamping corresponds to the use of the Time Stamp Protocol 
> (RFC 3161)
> * id-kp-emailProtection corresponds to the use of CMS (RFC 5652) as 
> used by S/MIME (RFC 8551)
>
> The current draft [3] fails to properly justify the need for an 
> IANA-defined EKU within introduction, and fails to define any 
> practical protocol that this key usage should be bound to. It 
> intentionally and explicitly leaves it ambiguous on the 
> appropriateness or inappropriateness of its use, and thus fails to 
> provide any interoperable value. The draft suggests that there is 
> value in assigning from the IANA arc, but fails to provide any 
> practical or technical justification to that effect.
>
> These are, I believe, blockers towards the adoption of the work: 
> Without a clear justification that both informs the goal and the 
> potential scope of work, I do not believe the draft should be adopted 
> as a work item for the WG.
>
> At its core, the value provided for this EKU is to indicate a 
> locally-interpreted meaning which lacks interoperability, namely: 
> "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 service or a software". That is, it seeks to assign 
> semantic meaning to an area subject to local policy (e.g. a naming 
> authority). Using a policy OID appropriate for the local naming 
> authority is entirely appropriate and suitable, but a generic OID to 
> indicate a certificate is subject to "a" naming authority is not 
> valuable in and of itself.
>
> [1] 
> https://datatracker.ietf.org/meeting/111/materials/slides-111-lamps-sessa-general-purpose-eku-for-document-signing-00 
> <https://datatracker.ietf.org/meeting/111/materials/slides-111-lamps-sessa-general-purpose-eku-for-document-signing-00>
> [2] 
> https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3 
> <https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.3>
> [3] 
> https://datatracker.ietf.org/doc/html/draft-ito-documentsigning-eku-01 
> <https://datatracker.ietf.org/doc/html/draft-ito-documentsigning-eku-01>
>
> On Mon, Jul 26, 2021 at 6:13 PM Russ Housley <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     We have already discussing the assignment of an object identifier
>     for document signing, and we had a presentation at IETF 111.
>     Following the IETF 111 presentation, no one spoke against against
>     adoption of this work.  This call is to see if there is rough
>     consensus for the LAMPS WG to proceed with this work.
>
>     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 14 August 2021.
>
>     For the LAMPS WG Chairs,
>     Russ
>     _______________________________________________
>     Spasm mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/spasm
>     <https://www.ietf.org/mailman/listinfo/spasm>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm