Re: Critical certificate policies extension

Inline...

On 7/11/22, 11:59 AM, "pkix on behalf of Niklas Matthies" <[email protected] on behalf of [email protected]> wrote:

    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)

[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.

    >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.

[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."



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