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

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

My preference is for more generic KU and EKU. 
In practice, “more certificates -> more troubles”. ;-)

Regards,
Uri

> On Nov 18, 2021, at 12:15, Tadahiko Ito <[e-mail]> wrote:
> 
> 
> Hi Stefan,
> 
> Thanks for your comments.
> 
> > 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
> 
> While binding each and every protocol does have challenges, as you seen in the previous discussions, we are not opposed to that idea. For instance, in a automated authentication system, it is effective to assign an EKU to a protocol.
> However, we recognize that there are some use cases where assigning a EKU per protocol is not realistic. An example is with a PIV card which has limited amount of slots which would not scale if there are too many EKUs per protocol which equates to many keys on the card. This is one of the cases we had in mind for having a general document signing EKU.
> 
> I think it is rational to bind EKUs to specific protocols for many use cases.
> However, as such practices become more widely use, some difficult-to-bind applications would appear, and we need some choices for those application.
> (I believe it is similar to basket clause in the legal systems, and common approach to deal with classification.)
> For example, as it was mentioned on slide 3 of IETF111's presentation and also on the I-D, we have introduced, or rather, allowed a bad practice of using email protection or code sign EKU for document signing to infest.
> <https://datatracker.ietf.org/meeting/111/materials/slides-111-lamps-sessa-general-purpose-eku-for-document-signing-00>
> We believe that our approach is a rational and valid way to solve this problem by means other than making 5280bis.
> 
> > 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.
> 
> We believe beyond what we described in section 4 is something dependent on the policy which the relying party or the relaying party software follows. We gave enough room to accommodate myriads of policies hence, the name “general”.
> 
> In this draft, we focused on describing the mechanism as much as possible and tried to be policy neutral.
> That should be defined by the policy body (if applicable). Also please note that not all of the document signing schemes have governing policy bodies, for example, the document signing in RFC8358.
> 
> > "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.
> 
> We received the same comment regarding this part and will be fixed in the next revision.
> We believe this does not affect the WG adoption.
> 
> Thanks,
> 
> Tadahiko
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm