Re: Critical certificate policies extension

Path validation treats policy OIDs as abstract OIDs and performs the
algorithm specified in Section 6.  Note that path validation input includes
a set of acceptable certificate policies OIDs to the user/application.

So, as long as one of the acceptable policy OIDs or a properly mapped OID is
in the certificates, other OIDs do not matter.

I am simplifying the concept to be brief as other policy related extensions
play a role as described in Section 6 of RFC 5280. 

-----Original Message-----
From: pkix [mailto:[email protected]] On Behalf Of Peter Gutmann
Sent: Monday, July 11, 2022 10:53 AM
To: Niklas Matthies <[email protected]>; [email protected]
Subject: Re: [pkix] Critical certificate policies extension

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.

>despite the RFC explicitly stating for the former that "No action is 
>mandated by this specification regardless of the criticality value 
>asserted for the extension"),

That sentence is preceded by "Processing requirements for this qualifier are
a local matter", so it's saying "what you do with this is up to you, we're
not going to mandate anything".  So this part makes sense too.

>1. Does that Java behavior make any sense?

Seems to.

>2. What would be the correct behavior for unknown policy OIDs without 
>qualifiers, or with only CPSuri and/or UserNotice qualifiers?

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.

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

Peter.

_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix