Re: [pkix] Critical certificate policies extension

[Niklas Matthies <[e-mail]>]

Dear Carl,

Thanks for your reply.

On Mon 2022-07-11 at 15:28h, Carl Wallace wrote on pkix:
>On 7/11/22, 11:59 AM, "pkix on behalf of Niklas Matthies" <[e-mail] on behalf of [e-mail]> wrote:
>    On Mon 2022-07-11 at 14:52h, Peter Gutmann wrote on pkix:
:
>    >... and if the implementation has been configured to do so via 
>    >the
>    >rejectPolicyQualifiers flag.  So it's doing what the user asked it to do.
>
>    Yes, but the flag is set by default, and the documentation [2] notes
>    that if it is not set, then the implementation is not PKIX compliant
>    by itself. This suggests that the implementers believed that the check
>    triggered by the flag is necessary for PKIX compliance. What I thus
>    don't understand is (a) why they restricted it to checking the
>    qualifiers, but at the same time are fine with arbitrary policy OIDs,
>    and to a lesser degree (b) why they didn't make an exception for the
>    CSPuri and UserNotice qualifiers whose presence clearly(?) should not
>    affect path validation.
:
>[CW] I don't know why this decision was made, but it's possibly due 
>to the fact that you can already address the policy OIDs using the 
>user supplied policy set but there's no corresponding way to get at 
>qualifiers.

Right, maybe that was the thinking. I still don't think that it makes 
a lot of sense, because either the specific policy is a binary thing 
regarding path validity (either accept or reject based on the policy 
OID, without additional conditions having to be checked), in which 
case that could as well cover qualifiers, or the specific policy 
requires additional conditions to be checked for the path to be valid, 
in which case application-specific code is required that could as well 
also check the qualifiers. 

The last sentence you quote below ("Policy qualifiers may, at the 
option of the certificate user, be processed or ignored"), still 
present in at least the 11/2008 version of X.509 (thus post-dating RFC 
5280), would explain the presence of the flag, but still does not 
explain the particular way in which the Java implementation handles 
qualifiers in critical policies extensions.

:
>    Right. So I gather that rejecting all certificates containing a
>    critical certificate policies extension with an unknown policy OID
>    would be a valid interpretation of the RFC requirements I cited.
>
>[CW] I think that would probably cause unnecessary path validation 
>failure. In some environments, certs are loaded up with policy OIDs 
>and most of them likely don't matter to you. There is a change noted 
>in RFC5280 on this topic:  "The path validation algorithm specified 
>in Section 6 no longer tracks the criticality of the certificate 
>policies extensions in a chain of certificates. In RFC 3280, this 
>information was returned to a relying party." Here's some language 
>from an old X.509 edition that is more consistent with what you are 
>suggesting (though only if all policies in the valid policy set are 
>unknown). The language here may also be why the decision referenced 
>above was made (since it leaves open the possibility for non-standard 
>qualifier processing).
>
>	"If the extension is flagged critical, it indicates that the 
>	certificate shall only be used for the purpose, and in 
>	accordance with the rules implied by one of the indicated 
>	certificate policies. The rules of a particular policy may 
>	require the certificate-using system to process the qualifier 
>	value in a particular way. If the extension is flagged 
>	non-critical, use of this extension does not necessarily 
>	constrain use of the certificate to the policies listed. 
>	However, a certificate user may require a particular policy to 
>	be present in order to use the certificate (see clause 10). 
>	Policy qualifiers may, at the option of the certificate user, 
>	be processed or ignored."

Thanks for pointing that out.

As section 6.1 notes, clients are not required to support all 
extensions processed in the path validation algorithm, but must reject 
the certificate if such an unsupported extension is marked as 
critical. In the context of the path validation algorithm, marking a 
certificate policies extension as critical thus only has the effect of 
ensuring that it is processed as specified in section 6.1 (which 
includes the handling of policy qualifier sets). The processing of any 
additional "rules implied by one of the indicated certificate 
policies" would thus be out-of-scope for the path validation 
algorithm.

That would fit with the following note in X.509 (2008):

     NOTE – If validation is successful, the certificate-using system 
     may still choose not to use the certificate as a result of values 
     of policy qualifiers or other information in the certificate.

With regard to policy qualifiers, there is also the following text in 
X.509 (2008):

     The optional qualifiers are not used in the certification path
     processing procedure, but relevant qualifiers are provided as an 
     output of that process to the certificate using application
     to assist in determining whether a valid path is appropriate for 
     the particular transaction.

My current conclusion is that the path validation according to RFC 
5280 can treat certificate policies extensions mechanically and does 
not need to know any policy-specific (or qualifier-specific) rules 
even in the case of critical extensions. The requirements of RFC 5280 
section 4.2.1.4 paragraph three, which specifically refer to path 
validation software, thus would only refer to that mechanical 
processing.

Nevertheless, the following sentence from X.509 (2008) (which you 
already quoted above)

     If the extension is flagged critical, it indicates that the
     certificate shall only be used for the purpose, and in
     accordance with the rules implied by one of the indicated
     certificate policies. The rules of a particular policy may require 
     the certificate-using system to process the qualifier value in a 
     particular way.

would arguably still require X.509-compliant client applications, in 
addition to path validation, to either know and observe the implied 
rules in the case of a critical extensions, or else to reject the 
respective certificate.

Niklas