IETF Logo Mail Archive

Re: [pkix] Critical certificate policies extension

Santosh Chokhani <santosh.chokhani@gmail.com> Mon, 11 July 2022 15:23 UTC

Return-Path: <santosh.chokhani@gmail.com>
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 5D4D4C15948B for <pkix@ietfa.amsl.com>; Mon, 11 Jul 2022 08:23:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 L5FQDS8_TKP3 for <pkix@ietfa.amsl.com>; Mon, 11 Jul 2022 08:23:21 -0700 (PDT)
Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E48C15AB6B for <pkix@ietf.org>; Mon, 11 Jul 2022 08:23:21 -0700 (PDT)
Received: by mail-qt1-x82e.google.com with SMTP id ck6so7271966qtb.7 for <pkix@ietf.org>; Mon, 11 Jul 2022 08:23:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=B9y6pktFoPyMCxMLXpofx5SpgOe1K9noDOcjBw0NWBU=; b=cEYUD4HDM03uKQfoKwgq9IXmyN5vQdhpYYZiiMj2RJf5MbHaHQR25era/6MJ1O/NRF kdmqsCIPCJ5naxcjoQcp22Laem3eglfi3Hh8d60bFInSeL9EiLgYqtb9+9o5TvLbwoxi Mi3UF6lmE5iTImmT+C17vPl8eHUSvRfAdL+tJzqa6imCWFNtOdps4wResNdGhH0Fy7nf E+Qc64h0ma8B+tJWDtsbD9ZIqULDd2S+8GOjZ0DnDuMYG75PZVUXzyRR/YZ8pjbCvREj Erm835LlC4dxXp4Xf5rxGguOqkv2HnxW5mkvKT0/91srGrVt7LOps8M28PnQWUIq2gFA otgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=B9y6pktFoPyMCxMLXpofx5SpgOe1K9noDOcjBw0NWBU=; b=oJhguX1c3xncBUtdX7M/fdy3tHSFHGLRGsHxsR0SrTOHj5Rn29k2xrUIcL7VyzUwQg rvBY2YQT+euziy69vZzAlKq156umRwrad0sz/k+6+nNjsPn+q4RPHY82iBtOz5YDcIY4 LHl1rUM9sa2wJbPL+fYGS+5LroOWpAPwl0susPQ1Dsu4ocre86HKOmKMXovLsCs5m919 qiTwnDhpZ8CP1TNeEXIr/XsxvnYjHrMJ631TFpWYyVWVosm4Ny/xBobrwgW5WohhsUPG NcbuRCTBXLDQ6M8Jg+82ykiBo5Fe6wSekDW9USXPS+kElSdbJ4+81/nMgg3mgPMOo7ra nMDA==
X-Gm-Message-State: AJIora9VG+JAfAt7ipe+swsSn3V7NNC3lpXflIdcfuS0ELVEdeJQ090y wc6DzRs8aZrmeitwNVNLJBijtEp9eEE=
X-Google-Smtp-Source: AGRyM1u9AMIySXj82lMgtRWUWIpQelq6ZMBBsbEUkBcYrA0UZsq59TmUYDXQAgGw36nDOvD9H2d8jg==
X-Received: by 2002:ac8:4e95:0:b0:31c:56db:107b with SMTP id 21-20020ac84e95000000b0031c56db107bmr14540617qtp.230.1657552999612; Mon, 11 Jul 2022 08:23:19 -0700 (PDT)
Received: from SantoshBrain (pool-173-73-190-66.washdc.fios.verizon.net. [173.73.190.66]) by smtp.gmail.com with ESMTPSA id bl29-20020a05620a1a9d00b006af45243e15sm6710802qkb.114.2022.07.11.08.23.18 for <pkix@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Jul 2022 08:23:18 -0700 (PDT)
From: Santosh Chokhani <santosh.chokhani@gmail.com>
To: pkix@ietf.org
References: <YswzrpCXx+IMjeYo@nmhq.net> <SY4PR01MB6251A6E61E56A33BB666B575EE879@SY4PR01MB6251.ausprd01.prod.outlook.com>
In-Reply-To: <SY4PR01MB6251A6E61E56A33BB666B575EE879@SY4PR01MB6251.ausprd01.prod.outlook.com>
Date: Mon, 11 Jul 2022 11:23:17 -0400
Message-ID: <122e01d8953a$25f0f5e0$71d2e1a0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQIEza1nildCHMl60AA/Jv9Qknt2WQKPMBqHrQxaocA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/OM6KCkLhIL5d2GLQbjhW6xvx2s0>
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:23:22 -0000

Path validation treats policy OIDs as abstract OIDs and performs the
algorithm specified in Section 6.  Note that path validation input includes
a set of acceptable certificate policies OIDs to the user/application.

So, as long as one of the acceptable policy OIDs or a properly mapped OID is
in the certificates, other OIDs do not matter.

I am simplifying the concept to be brief as other policy related extensions
play a role as described in Section 6 of RFC 5280. 

-----Original Message-----
From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Peter Gutmann
Sent: Monday, July 11, 2022 10:53 AM
To: Niklas Matthies <pkix@nmhq.net>; pkix@ietf.org
Subject: Re: [pkix] Critical certificate policies extension

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.

>despite the RFC explicitly stating for the former that "No action is 
>mandated by this specification regardless of the criticality value 
>asserted for the extension"),

That sentence is preceded by "Processing requirements for this qualifier are
a local matter", so it's saying "what you do with this is up to you, we're
not going to mandate anything".  So this part makes sense too.

>1. Does that Java behavior make any sense?

Seems to.

>2. What would be the correct behavior for unknown policy OIDs without 
>qualifiers, or with only CPSuri and/or UserNotice 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.

So probably the best behaviour is "try and be consistent, and document what
you do somewhere".

Peter.

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

v2.23.0 | Report a Bug | By Email