Re: [pkix] Critical certificate policies extension

Niklas Matthies <pkix@nmhq.net> Tue, 19 July 2022 19:28 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 22673C13C527 for <pkix@ietfa.amsl.com>; Tue, 19 Jul 2022 12:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 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] 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 EUDHyKxpOBUY for <pkix@ietfa.amsl.com>; Tue, 19 Jul 2022 12:28:14 -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 93A1FC13C518 for <pkix@ietf.org>; Tue, 19 Jul 2022 12:28:13 -0700 (PDT)
Received: from matthies by mail.nmhq.net with local (Exim 4.94.2) (envelope-from <pkix@nmhq.net>) id 1oDst6-005KAb-Dh for pkix@ietf.org; Tue, 19 Jul 2022 21:28:08 +0200
Date: Tue, 19 Jul 2022 21:28:08 +0200
From: Niklas Matthies <pkix@nmhq.net>
To: pkix@ietf.org
Message-ID: <YtcFyClwxfzMypdj@nmhq.net>
Mail-Followup-To: pkix@ietf.org
References: <YswzrpCXx+IMjeYo@nmhq.net> <SY4PR01MB6251A6E61E56A33BB666B575EE879@SY4PR01MB6251.ausprd01.prod.outlook.com> <YsxIxNEjEauRzFsP@nmhq.net> <SY4PR01MB625137F3FE5F6324F7D143C8EE889@SY4PR01MB6251.ausprd01.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Disposition: inline
In-Reply-To: <SY4PR01MB625137F3FE5F6324F7D143C8EE889@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/gqaGLnztFcbmECflx6dLFbQ9P2E>
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: Tue, 19 Jul 2022 19:28:19 -0000

On Thu 2022-07-14 at 08:31h, Peter Gutmann wrote on pkix:
>Niklas Matthies <pkix@nmhq.net> writes:
>
>>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.
>
>That seems incorrect, I'd expect it to be off by default.

It is on by default. From the documentation I linked:

     When a PKIXParameters object is created, this flag is set to true.
     This setting reflects the most common (and simplest) strategy for
     processing policy qualifiers. Applications that want to use a more
     sophisticated policy must set this flag to false.

>>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.
>
>Uhh... pass.  Technically it's OK if it's in the initial policy set, 
>but then you get into the rathole of what it means to "regcognise" an 
>extension.  Which was also debated endlessly on the list, see e.g. 
>the PKIX thread "What is meant by recognizing critical extensions?"

Right. At the very least, it makes sense to me to apply the principle 
that the critical flag should not make a difference for elements where 
the applicable requirements are fully supported. That is, the critical 
flag would only ever used along the lines of:

     if (I_do_not_know_this_extension ||
         I_do_not_comply_with_some_applicable_requirement_for_this_extension)
     {
         if (extension_is_critical)
         {
             reject_certificate();
         }
     }

And never along the lines of:

     if (I_know_this_extension_and_comply_with_all_applicable_requirements)
     {
         if (extension_is_critical)
         {
             do_something();
         }
         else
         {
             do_something_different();
         }
     }

The set of "applicable requirements" can of course still be unclear. 
But you don't have different sets of applicable extension-specific 
requirements depending on whether the extension is critical or not.

Niklas