988462 - (mozilla::pkix) returns success on criticial certificate policies even tough it does not handle them correctly

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Camilo Viecco (:cviecco)]

While testing certificate policies I noticed that mozilla::pkix always consumes the certificate policies, even in the case where they are marked criticial. Mozilla pkix does not handle correctly processing non-ev certificates with critical certificate policies we accept them (we dont check).

Example:
ee_critical_policy_a -> int_policy_b -> CA

classic rejects this ee_cert, moz::pkix accepts it.

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

It makes sense that NSS classic would reject a critical policy extension since it doesn't process certificate policies at all. It would be better to compare to libpkix and/or Windows's implementation.

mozilla::pkix does understand certificate policies, so it makes sense that we don't reject critical policy extensions. Note that mozilla::pkix may choose to ignore the policy information, but unless there's something in the spec that says we can't ignore it, then explicitly deciding to ignore the policy information is good enough to consider the extension "understood" for the purpose of the critical bit.

Comment 2

[Camilo Viecco (:cviecco)]

(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #1)
> It makes sense that NSS classic would reject a critical policy extension
> since it doesn't process certificate policies at all. It would be better to
> compare to libpkix and/or Windows's implementation.
> 
> mozilla::pkix does understand certificate policies, so it makes sense that
> we don't reject critical policy extensions. Note that mozilla::pkix may
> choose to ignore the policy information, but unless there's something in the
> spec that says we can't ignore it, then explicitly deciding to ignore the
> policy information is good enough to consider the extension "understood" for
> the purpose of the critical bit.

If I read http://tools.ietf.org/html/rfc5280#section-4.2.1.4 correctly (in parragraph 2)
the precense of a policy in an intermeditate (or CA) requires that all certs down to the 
ee to have that policy (I would even argue that this is similar to EKU nesting but
explicit in the RFC). If I have a verification library that understands certificate policies
I would expect 

ee_p1 -> int_p2 -> ca       -> reject
ee_p1 -> int_p1_p2 -> ca    -> accept
ee_p1_p2 -> int_p1 -> ca    -> reject
ee_p1_p2 -> int_p1_p2 -> ca -> accept


Dont you agree?

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to Camilo Viecco (:cviecco) from comment #2)
> If I read http://tools.ietf.org/html/rfc5280#section-4.2.1.4 correctly (in
> parragraph 2)
> the precense of a policy in an intermeditate (or CA) requires that all certs
> down to the ee to have that policy

Here is paragraph 2:

>   In an end entity certificate, these policy information terms indicate
>   the policy under which the certificate has been issued and the
>   purposes for which the certificate may be used.  In a CA certificate,
>   these policy information terms limit the set of policies for
>   certification paths that include this certificate.  When a CA does
>   not wish to limit the set of policies for certification paths that
>   include this certificate, it MAY assert the special policy anyPolicy,
>   with a value of { 2 5 29 32 0 }.

I think you are interpreting this to mean that a certificate is invalid if it contains policy OIDs that the issuer chain don't contain. However, that is not what the above paragraph says and I don't think that is what it intended. I

Please see http://tools.ietf.org/html/rfc5280#section-6.1.2:

"If valid policies do not exist at this stage in the certification path validation, the tree is set to NULL.  Once the tree is set to NULL, policy processing ceases."

and http://tools.ietf.org/html/rfc5280#section-6.1.3

"If the certificate policies extension is present in the certificate and the valid_policy_tree is not NULL, [then verify policies using the following steps]"

One way to think about this is that the certificate verification library answers TWO questions: (1) Is the certificate chain valid? and (2) Which policies is it valid for? It is possible for a certificate chain to be valid, but be valid for no policies.

Another way to think about this is to simply apply the algorithm in section 6.1 with our non-EV validation settings of:

   user-initial-policy-set = { any-policy }
   initial-explicit-policy = false

For the record, our EV validation settings would be:

   user-initial-policy-set = { <the first EV policy found in the EE cert> }
   initial-explicit-policy = true

And the way that we verify for EV and then for non-EV in CertVerifier is equivalent to:

   user-initial-policy-set = { <the first EV policy found in the EE cert> }
   initial-explicit-policy = false

Comment 4

[Camilo Viecco (:cviecco)]

You are correct.