Re: [Trans] defining "mis-issuance"

[Santosh Chokhani <[e-mail]>]

Steve,

See I will respond to the other thread you created for path validation.  That seems to be a more appropriate place.

I will be sure to include the EKU processing language there.

From: Trans [mailto:[e-mail]] On Behalf Of Stephen Kent
Sent: Monday, September 29, 2014 10:53 AM
To: [e-mail]
Subject: Re: [Trans] defining "mis-issuance"

Santosh,

Steve,

I read 6962-bis saying submission of certificate chain.

Why not add path validation to the list of rules you defined below.  That would be good given the wide variance in how browsers process chains.  This gives us another opportunity at log level to have correct logic for path validation.
I believe 6962-bit already requires a log operator to validate the cert chain to
one of the roots from which it accepts SCT requests, based on text in Section 3.1.
But I can add a specific reminder of the need to do that.


Note that if one follows CABF, unlike RFC 5280 and X.509, EKU is processed somewhat akin to certificate policy (less policy mapping).
Can you point to the CABF text that makes this clear? Also, I'd be thankful if you can
provide suggested changes to my text to highlight this.


On a side note, I fail to see CABF requirement with respect to interaction between name constraints and EKU.
I read Section 9.7 of the DV (1.1.9) spec as implying a linkage between the two, but
the wording is somewhat confusing to me.

Steve