Re: Critical certificate policies extension

Peter,

Thanks for your reply.

On Mon 2022-07-11 at 14:52h, Peter Gutmann wrote on pkix:
>Niklas Matthies <[email protected]> writes:
>
>>The reason I'm asking is that the Java path building and validation
>>implementation (formerly by Sun/Oracle, now OpenJDK) by default rejects
>>certificates with a critical certificate policies extension if it contain any
>>qualifiers [1]
>
>... 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.

[2] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/security/cert/PKIXParameters.html#setPolicyQualifiersRejected(boolean)

>This was one of the many parts of the standard that, when it was 
>originally discussed, no two people could agree on, see e.g. the 
>thread "Dave's Critical Proposal" from 1997.  There were many more 
>like that.

Thanks for that pointer. Just for reference, Dave's actual proposal 
ssems to be [3], and further threads discussing the topic are anchored 
at [4] and [5].

[3] https://mailarchive.ietf.org/arch/msg/pkix/Hl3wPdiVIjNOL4rJ9NgQQjxAo08/
[4] https://mailarchive.ietf.org/arch/msg/pkix/cXFcS3bcZUfDMp5YA_A0GizjJt8/
[5] https://mailarchive.ietf.org/arch/msg/pkix/jvera4YQZvytTTQtX4zsziPcr6E/

>So probably the best behaviour is "try and be consistent, and 
>document what you do somewhere".

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.

Niklas