Re: Critical certificate policies extension

On Tue 2022-07-12 at 07:28h, [email protected] wrote on pkix:
:
>The meaning of certificates should almost always be set at design 
>time, and never left to the imagination of developers.  There 
>shouldn't be any subtle decision making at run time.  When Niklas's 
>suggests the "software must know the meaning of the specific policy 
>OID", I say 'knowing' is simple. The logic should be hard wired: Is 
>the OID in the accepted Policy set or not? If not, then the 
>certificate is not fit for purpose for the transaction being
>attempted. 

The consequence is that applications can't just accept an open-ended
set of policies (when marked as critical), because they can't possibly 
know the rules implied by all the potential policies.

The problem, as I see, is that the critical flag has on the one hand 
the meaning of ensuring that the policy sets are processed as 
specified for the path validation algorithm, but on the other hand may 
also have the intention of forcing policy-specific rules to be 
applied. There is no way for a certificate issuer to force the path 
validation processing but at the same time to indicate to client 
applications that there are no further rules to be obvserved, which is 
what would allow clients that don't know the specific policy to still 
accept the certificate.

Niklas