[cabfpub] A conflict about EKU with PKIX

[Ryan Sleevi]

On Sun, Mar 19, 2017 at 6:26 PM, Peter Bowen via Public <public at cabforum.org
> wrote:

> That being said, I am well aware there are large PKI deployments that
> depend on the alternative meaning.  This keeps being the sticking point
> when trying to propose updating the standards.
>

As Adam pointed out, how so? These are complimentary, especially if we
presume these "EKUs apply only to the cert" implementations strictly adhere
to RFC 5280's promotion of Postel's Law, which is that they should not
enforce the profile given within 5280/reject deviance from it.


> I’m all in favor of adding a new constraint type explicitly for EKU,
> adding a new flag to indicate that the EKU constraint is “indirect”
> (meaning down the path), or coming up with some other solution.  But I do
> think that we need to allow both the direct and indirect interpretations
> co-exist and not set requirements that assume one implementation or the
> other.
>

Of course, to introduce such a security-critical restriction, we must
naturally presume it should be marked critical, correct?


> I also favor, in this specific case, supporting existing PKIs that issue
> identity certificates, as it seems like a very reasonable use case to be
> able to sign an email using my government issued ID.
>

Is this a remark about product direction/strategy? I'm not sure how to take
it.

Regarding the use of a single certificate/key pair across multiple
application spaces, we naturally should be concerned with any possibility
of cross-protocol attacks and confusion.

- The risk of using the same key in the context of both encryption and
signing
- The risk of using the same key across distinct signature algorithms
- The risk of messages signed with the same key being interpreted in
different contexts depending on the protocol (cross-protocol attacks)

These are all compelling reasons why such a reasonable request is not
entirely reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170321/9712e878/attachment-0003.html>