Re: [pkix] Critical certificate policies extension

Niklas Matthies <pkix@nmhq.net> Mon, 11 July 2022 15:59 UTC

Return-Path: <pkix@nmhq.net>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5ABC15A739 for <pkix@ietfa.amsl.com>; Mon, 11 Jul 2022 08:59:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_1l1If_nSiC for <pkix@ietfa.amsl.com>; Mon, 11 Jul 2022 08:59:10 -0700 (PDT)
Received: from mail.nmhq.net (mail.nmhq.net [95.129.49.110]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FC70C15948B for <pkix@ietf.org>; Mon, 11 Jul 2022 08:59:09 -0700 (PDT)
Received: from matthies by mail.nmhq.net with local (Exim 4.94.2) (envelope-from <pkix@nmhq.net>) id 1oAvoK-004hhM-BS for pkix@ietf.org; Mon, 11 Jul 2022 17:59:00 +0200
Date: Mon, 11 Jul 2022 17:59:00 +0200
From: Niklas Matthies <pkix@nmhq.net>
To: pkix@ietf.org
Message-ID: <YsxIxNEjEauRzFsP@nmhq.net>
Mail-Followup-To: pkix@ietf.org
References: <YswzrpCXx+IMjeYo@nmhq.net> <SY4PR01MB6251A6E61E56A33BB666B575EE879@SY4PR01MB6251.ausprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <SY4PR01MB6251A6E61E56A33BB666B575EE879@SY4PR01MB6251.ausprd01.prod.outlook.com>
X-Clacks-Overhead: GNU Terry Pratchett
X-Editor: VIM - Vi IMproved 8.2
X-Operating-System: Linux 4.4.268 x86_64
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/1IUGY5HbPJD9pr4jh0a50bBVZDo>
Subject: Re: [pkix] Critical certificate policies extension
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Jul 2022 15:59:11 -0000

Peter,

Thanks for your reply.

On Mon 2022-07-11 at 14:52h, Peter Gutmann wrote on pkix:
>Niklas Matthies <pkix@nmhq.net> 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