Re: [pkix] Critical certificate policies extension

swilson@lockstep.com.au Mon, 11 July 2022 21:28 UTC

Return-Path: <swilson@lockstep.com.au>
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 5FC2EC18872A for <pkix@ietfa.amsl.com>; Mon, 11 Jul 2022 14:28:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.426
X-Spam-Level:
X-Spam-Status: No, score=-1.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.377, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=no 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 6gl0fCOMukmo for <pkix@ietfa.amsl.com>; Mon, 11 Jul 2022 14:28:45 -0700 (PDT)
Received: from smtp78.iad3a.emailsrvr.com (smtp78.iad3a.emailsrvr.com [173.203.187.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96C54C188724 for <pkix@ietf.org>; Mon, 11 Jul 2022 14:28:45 -0700 (PDT)
Received: from app11.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id B8711423E for <pkix@ietf.org>; Mon, 11 Jul 2022 17:28:43 -0400 (EDT)
Received: from lockstep.com.au (localhost.localdomain [127.0.0.1]) by app11.wa-webapps.iad3a (Postfix) with ESMTP id 6DA1CA1DDD for <pkix@ietf.org>; Mon, 11 Jul 2022 17:28:43 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: swilson@lockstep.com.au, from: swilson@lockstep.com.au) with HTTP; Tue, 12 Jul 2022 07:28:43 +1000 (AEST)
X-Auth-ID: swilson@lockstep.com.au
Date: Tue, 12 Jul 2022 07:28:43 +1000
From: swilson@lockstep.com.au
To: pkix@ietf.org
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_20220712072843000000_59912"
Importance: Normal
X-Priority: 3 (Normal)
X-Type: html
In-Reply-To: <YswzrpCXx+IMjeYo@nmhq.net>
References: <YswzrpCXx+IMjeYo@nmhq.net>
X-Client-IP: 2001:8003:ccf8:bf00:186e:e097:b17a:c3be
Message-ID: <1657574923.44564356@apps.rackspace.com>
X-Mailer: webmail/19.0.16-RC
X-Classification-ID: 324f2311-e444-423f-8cc9-1c458e6a2f3a-1-1
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/bmc3GzYRlaWs8nvenUq1xTrb3ng>
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 21:28:49 -0000

 

Niklas Matthies asked:

"What exactly does 'able to interpret' mean? Does it mean that the
software must know the meaning of the specific policy OIDs (and
qualifiers), or does it just mean that it must understand the
extension syntactically ...?"

 

I always thought that "interpret" was in the eye of the implementer and in the context of the certificate designer / policy setter.  It seems to me that the criticality extension has been chronically underutilised. PKI was bitten by the "openness" and "interoperability" bugs -- we wanted all certifictes to be as useful as possible. But if I pop my Qantas frequent flyer card into an ATM, I should hope the machine will spit it out.      

 

The most powerful certificates are for specific purposes. SIM cards, EMV cards, cable TV boxes ... these are all specific credentials designed for specific purposes.  They're not supposed to be "open". Closure is good! Some closed systems (like EMV) are so enormous we forget that they're close nevertheless. 

 

So I never understood why the X.509 criticality feature seemed to be derided. 

 

If a certificate designer / policy setter has a specific purpose in mind, then they will communicate that purpose to the community of developers, and they will "understand" what the certificates are for before they write software . They will be able to interpret the extension (at design time). Any other software that comes across a purpose-specific certificate with a Critical extension, should take the hint. The certificate might be special. Special purpose. And reject the certificate if it's being presented out of context. 

 

The meaning of certificates should almost always be set at design time, and never left to the imagination of developers.  There shouldn't be any subtle decision making at run time.  When Niklas's suggests the "software must know the meaning of the specific policy OID", I say 'knowing' is simple. The logic should be hard wired: Is the OID in the accepted Policy set or not? If not, then the certificate is not fit for purpose for the transaction being attempted. 

 

Cheers, 

 

Steve.

 

Stephen Wilson

Managing Director

Lockstep Group

 

 

E:   swilson@lockstep.com.au

M:   +61 (0)414 488 851

W:  http://lockstep.com.au

T:   @steve_lockstep

 

Lockstep Consulting provides independent specialist advice and analysis

on digital identity and privacy.  Lockstep Technologies develops unique

new verifiable credentials and data protection solutions.

 

 

 

 

 

-----Original Message-----
From: "Niklas Matthies" <pkix@nmhq.net>
Sent: Tuesday, 12 July, 2022 12:29am
To: pkix@ietf.org
Subject: [pkix] Critical certificate policies extension

Dear all,

Regarding the certificate policies extension, RFC 5280 section 4.2.1.4
states:

If this extension is critical,
the path validation software MUST be able to interpret this extension
(including the optional qualifier), or MUST reject the certificate.

What exactly does "able to interpret" mean? Does it mean that the
software must know the meaning of the specific policy OIDs (and
qualifiers), or does it just mean that it must understand the
extension syntactically and perform the checks specified in section
6.1 (path validation)?

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] (even for the standard qualifiers
CPSuri and UserNotice, 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"), but is fine with
critical certificate policies extensions specifying custom policy OIDs
as long as they do not have any qualifiers.

Regarding the "MUST" requirements quoted above:

1. Does that Java behavior make any sense?
2. What would be the correct behavior for unknown policy OIDs without
qualifiers, or with only CPSuri and/or UserNotice qualifiers?
3. Does it make a difference whether the extension occurs in an EE or
CA certificate?

Any clarification would be greatly appreciated.

Niklas

[1] https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/security/provider/certpath/PolicyChecker.java#L483

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