Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning

Santosh Chokhani <santosh.chokhani@gmail.com> Sun, 28 February 2021 21:49 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 172B83A1D00 for <pkix@ietfa.amsl.com>; Sun, 28 Feb 2021 13:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.197
X-Spam-Level:
X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C44AxEr9NwBy for <pkix@ietfa.amsl.com>; Sun, 28 Feb 2021 13:49:46 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E143A1CFB for <pkix@ietf.org>; Sun, 28 Feb 2021 13:49:46 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id 130so91176qkh.11 for <pkix@ietf.org>; Sun, 28 Feb 2021 13:49:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=pFiWMc12qMQFxrTzNrMTQ5Wl+8tM6Gg/llRC1KIX5zA=; b=eo0RmMKxacgxQuA05Luq01gT66D/KwCK330Byt5QUd8Q0VEPrgcJ0x3IUcCa124x0E C5zZIb4dt5eoknSQJkL90c+EmGWc+/KuXANxP8+OW8mS8rubU/FFoc/ZwBU43/bZ1ITp hl2Nf119Q1mAinYgy/6inzFRjp8GDSbLc6hOtbHpn9q/ouoHop4bRhFdu/46hhHMf4q5 F3Zj1U9BTYWV9/9CwZOBBADJHMgZH0EN/47UUvllHTwnU4Y7dRnM9QhvKQcMtdCqVwLN HFDcjCuCFoi7D0FqZNBYNf3VxRtiJDocQ8LEj/Md1LyN3MVeBhJ/7nk8NUVlfc+6Dseo yyyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=pFiWMc12qMQFxrTzNrMTQ5Wl+8tM6Gg/llRC1KIX5zA=; b=hpMQzraarMCqvsrYmE17cFkl+fBVzLTkGZI6rZOl52bh5QF4tvvsU+LPKZhd26sbWv 4fCtxoSTQolarBeMSJnAiwGmuurbXZGuQk2VV7uzcBLJeNYxQLMWTYebHCnQUIA3mJlS MKKFZlfcsQBAqPYOZqewVKK+kTpNmpt6NcRc4FEAwZrXpPP03pW+Y84H0zqCqYv6/cz3 LeEbBQkddUSYshrg5Vr10IUqtSDWsA0kLXw7YcJWAjnZc2J6+vtEjV1cPg+zrgiAQUuU DFS2EomdmOMFqEF9UrVEzcKDDEWMxIQIvvKZzYg+wRy0Y9SopBgxoWkysV5WF5DGfBzy wJjw==
X-Gm-Message-State: AOAM532DtfXX3Cdal11NuoqKlGmWgswm2e8dtICjySa/UCW5/4obL4rs Otvn9BgT4TxdXICZmMTdC8so8zV0oiYjgQ==
X-Google-Smtp-Source: ABdhPJzuE6p+O1T8NE7wYCzXGWlplagrCNnMYUZ+PNgKzvvPTe87ttQ4zBkRcdZJ0H5fEw4iyG3mxw==
X-Received: by 2002:a37:396:: with SMTP id 144mr11692824qkd.412.1614548982726; Sun, 28 Feb 2021 13:49:42 -0800 (PST)
Received: from SantoshBrain (pool-173-73-187-14.washdc.fios.verizon.net. [173.73.187.14]) by smtp.gmail.com with ESMTPSA id f8sm9824300qth.6.2021.02.28.13.49.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Feb 2021 13:49:42 -0800 (PST)
From: Santosh Chokhani <santosh.chokhani@gmail.com>
To: 'Stefan Santesson' <stefan@aaa-sec.com>, ryan@sleevi.com
Cc: 'IETF PKIX' <pkix@ietf.org>
References: <66550DC7-EE88-4F56-B491-03C6D3249720@aaa-sec.com> <CAErg=HFu1hkJytkJ5TiRq0SUH0uObwWESyynoTkm_PLBkg31jw@mail.gmail.com> <571CE4F3-38BB-4E3C-AA8C-336D40C2BB9B@aaa-sec.com>
In-Reply-To: <571CE4F3-38BB-4E3C-AA8C-336D40C2BB9B@aaa-sec.com>
Date: Sun, 28 Feb 2021 16:49:44 -0500
Message-ID: <018401d70e1b$a08dea80$e1a9bf80$@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0185_01D70DF1.B7B9B740"
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQKBqpUoG2dOjtl4vad6hyHHqOV54QGn1fTsAxe63TSo8uIKsA==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/-qOZPnvuA9TSVGIo9GyoP2tSWUM>
Subject: Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 28 Feb 2021 21:49:48 -0000

Stefan,

 

To add some color to EKU part, if the EKU was required that would mean the parent CA is  delegating the child CA to be authoritative for the revocation status of the certificates issued by the parent CA.  Clearly, we do not want that unless parent truly intends that.

 

From: pkix [mailto:pkix-bounces@ietf.org] On Behalf Of Stefan Santesson
Sent: Sunday, February 28, 2021 3:11 PM
To: ryan@sleevi.com
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning

 

Thanks Ryan.

 

For all practical uses I meant what you first stated. That is, the OCSP response is validated directly by the CA certificate.

The OCSP standard does not explicitly say anything about the CA certificate and from my perspective that is not strictly needed. As long as the OCSP response and the certificate is signed with the same key, I can validate the response using the CA certificate.

 

So in all important aspects of this, you confirm my assumptions.

 

Stefan Santesson 

 

From: Ryan Sleevi <ryan@sleevi.com <mailto:ryan@sleevi.com> >
Reply to: <ryan@sleevi.com <mailto:ryan@sleevi.com> >
Date: Sunday, 28 February 2021 at 20:52
To: Stefan Santesson <stefan@aaa-sec.com <mailto:stefan@aaa-sec.com> >
Cc: IETF PKIX <pkix@ietf.org <mailto:pkix@ietf.org> >
Subject: Re: [pkix] Authorised responders OCSP and id-kp-OCSPSigning

 

 

 

On Sun, Feb 28, 2021 at 2:27 PM Stefan Santesson <stefan@aaa-sec.com <mailto:stefan@aaa-sec.com> > wrote:

Came across this question on OCSP where I wander how various implementers chose to interpret the requirements.

And shamefully I can’t recall how we thought when we published this.

 

The text says that a CA can choose to either:

 

* Sign the OCSP response itself, or

* Explicitly delegate OCSP signing to another entity

 

It then states that delegation SHALL be indicated by inclusion of the id-kp-OCSPSigning extended key usage

 

So, as I read this, the id-kp-OCSPSigning extended key usage is NOT required if the CA issues OCSP responses itself using the same key as was used to sign the certificate.

This because there is no delegation taking place.

 

So I wander:

 

1.      Do people here agree with my interpretation

2.      Do implementations in general agree with this interpretation, or do they all enforce id-kp-OCSPSigning always?

 

As worded, no to both.

 

This may seem like a minor nit, but is an incredibly important and meaningful detail: it's not sufficient to say "same key", because that allows for (implicitly) the existence of a responder certificate that shares the same key, but otherwise different attributes, than the issuing CA.

 

If you meant "OCSP response directly signed by the CA certificate that signed the certificate being verified", then yes, there is no need for id-kp-OCSPSigning on the issuing CA certificate. I realize that keys sign, not certificates, but for purposes of this discussion, I mean the same (DN+SPKI) tuple, with the same X.509 issuer, serialNumber, and attributes as used to issue the certificate (i.e. the same certificate).

 

Given the recent confusion around intermediate/subordinate and the somewhat confused attempt to read organization distinctions rather than technical into terms like "CA", it seems an important bit to correct, to make sure we're talking about the same thing, unambiguously.

 

As to your second question, the answer is that there is significant divergence in what attributes are seen as essential with a directly-delegated responder (i.e. a certificate directly signed by the CA certificate that issued the certificate being verified). I am not aware of implementations that enforce id-kp-OCSPSigning always when the OCSP response is directly signed by the issuing CA certificate of the certificate being verified, but whether or not implementations consistently enforce id-kp-OCSPSigning, or require other, additional properties (e.g. the absence of a basicConstraints/the cA boolean being false, the presence of certain keyUsage attributes, direct-or-transitively signed) varies for those responses-issued-by-a-responder-issued-by-the-issuing-CA.

 

There is further variance for when systems allow local policy to locally configure responder certificates (i.e. without the CAs direct knowledge/participation/issuance), as this is expanded upon in RFC 6960, 4.2.2.2. From the RFC 6960 perspective, such locally configured responders are not required to present the EKU, but implementations may vary and otherwise require it.