Ryan, please could you expand on precisely how and why it's technically
'incorrect' to do, for example, the following...
Root (Certificate Policies: none, so effectively anyPolicy)
Intermediate (Certificate Policies: just the BR DV OID)
Leaf (Certificate Policies: the BR DV OID and 2.23.140.x.y.z)
...or even...
Root (Certificate Policies: none, so effectively anyPolicy)
Intermediate (Certificate Policies: a CA-specific EV OID)
Leaf (Certificate Policies: the same EV OID and 2.23.140.x.y.z)
?
In other words, under what RFC5280-conforming circumstances would the
fact that 2.23.140.x.y.z doesn't appear in the Intermediate certificate
actually make any difference to the outcome?
My reading of 5280 section 6 this morning (fueled by insufficient
coffee, I have to admit) was that: each of the policy OIDs in a cert are
processed independently; it's sufficient to match _just one_ OID in the
Leaf and Intermediate (in my examples above, that's the BR DV OID or the
CA-specific EV OID); therefore, the non-matching of 2.23.140.x.y.z would
never actually matter (as long as the BR DV OID, or the CA-specific EV
OID, or anyPolicy, are in the set of permitted policies).
On 02/05/17 15:52, Ryan Sleevi wrote:
Define valid?
Yes, it's totally fine to use the OID as a policy signifier in a way
that will not (negatively) impact validation, unless you attempt to
positively assert "Valid for this OID"
What I mean is that the leaf can use a number of OIDs to express the
policies upon which it was issued/validated. If the intermediate lacks
those OIDs, then you will not be able to validate (using RFC 5280) rules
for that specific policy OID (e.g. if you say "Tell me if this cert is
valid for this policy OID"), BUT that doesn't negatively impact policy
validation to have that OID (e.g. if you say "Tell me if this cert is
valid")
The subtlety here is whether or not it's conforming with the purpose of
policy OIDs, and whether or not we should overload that. There's an
argument that "Ah yes, we all know how to add policy OIDs" which makes
it quite appealing, but on the other hand, it creates the 'intentional
incorrectness' if the intermediate lacks these policy OIDs (as one would
presume).
I don't have _strong_ feelings about it, but was proposing a way that we
could do it "right" (new extension). If there are reasons within the
technical infrastructure that would make this difficult/impossible to do
in a timely fashion, certainly, the policy OID offers a solution, even
if 'technically' incorrect.
On Tue, May 2, 2017 at 6:02 AM, Rob Stradling via Public
<[email protected] <mailto:[email protected]>> wrote:
On 02/05/17 10:23, Gervase Markham via Public wrote:
On 02/05/17 10:18, Rob Stradling via Public wrote:
Or you could embed all of this into a single Certificate
Policy OID.
(off-list)
Would that not be problematic if, as a previous message in the
thread
noted, there wasn't an anyPolicy OID in the intermediate? Or am I
misunderstanding how this works?
Hi Gerv. I was about to reply "Oh yeah, you're right", but I
thought I'd first take another look at RFC5280 Section 6
(Certificate Path Validation)...
I *think* each of the policy OIDs in a leaf cert are processed
independently. That is, as long as at least 1 of the OID(s) matches
the expected set, it's valid.
But please seek a second opinion on that. I'm far from confident
that I understand correctly. :-)
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
