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
- [pkix] Critical certificate policies extension Niklas Matthies
- Re: [pkix] Critical certificate policies extension Peter Gutmann
- Re: [pkix] Critical certificate policies extension Santosh Chokhani
- Re: [pkix] Critical certificate policies extension Niklas Matthies
- Re: [pkix] Critical certificate policies extension Carl Wallace
- Re: [pkix] Critical certificate policies extension swilson
- Re: [pkix] Critical certificate policies extension Niklas Matthies
- Re: [pkix] Critical certificate policies extension Niklas Matthies
- Re: [pkix] Critical certificate policies extension Todd E. Johnson
- Re: [pkix] Critical certificate policies extension Peter Gutmann
- Re: [pkix] Critical certificate policies extension Niklas Matthies
- Re: [pkix] Critical certificate policies extension Peter Gutmann