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

[Tadahiko Ito <[e-mail]>]

Thanks Sleevi

>>* id-kp-emailProtection corresponds to the use of CMS (RFC 5652) as used
by S/MIME (RFC 8551)
I love to see those correspondances in the real world.
If certs were for SMIME, OID should be id-kp-emailProtection.
However, Certs with id-kp emailProtection does not mean certs are used for
SMIME.
We might not able to make clear 100%, but should be able to make it better.
That was the starting point of our proposal.

I think we need a concept like Basket Clause that does not have a negative
impact on other OIDs.
I understand that this OID alone may not be that valuable, but I think that
this OID is valuable to ensure the soundness of other OIDs.

If after several years, other EKUs for protocol specific Document sign were
assigned (although that would not be our job at least at IETF) and used as
common practice,
it will be great, and we will be happy to obsolete this EKU.
However, in the meantime, we strongly believe that this would be a viable
option for those who want to limit the usage to document signing without
substituting the EKU with id-kp-emailProtection or id-kp-codesigning.

Regards Tadahiko Ito