Re: [pkix] technical question about RFC 6960

Peter Bowen <pzbowen@gmail.com> Wed, 29 April 2020 14:57 UTC

Return-Path: <pzbowen@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 94E383A124E for <pkix@ietfa.amsl.com>; Wed, 29 Apr 2020 07:57:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 xJtPAPWwxMCH for <pkix@ietfa.amsl.com>; Wed, 29 Apr 2020 07:56:59 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 952CE3A1253 for <pkix@ietf.org>; Wed, 29 Apr 2020 07:56:58 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id g4so2971720ljl.2 for <pkix@ietf.org>; Wed, 29 Apr 2020 07:56:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yT/TJEKHboDAfIO6CXj+4CpRkzrNb91hKdAUUrheSj4=; b=LUh91cdz6EUKkMXoTdYc2qCnYeMJnmDvnmEzbv5O2pnuNhGpgODQaymwWM86A0oM4m CRo3ZAgk1v5fdqIe5Md4yE72DcMp6uRFRivq0KrQZig4ACNPDNfQyMG8Bjy6+0+P7HWu VpctF+E/hdNNgOspT+9eNNJJeWyL0SZb+geHfxm9VCDe8htuK+0yB7XHORQKOJzU0Vat INyQSjZiczWFqi8gwVFRkB7PZ3+WEAKlmxDISPxvypntZldx6V5Y1ra2J2GhBB8kp690 G/4GHJ/sw362vdVni0y+WCXmCk0Huy8+N2UmeYjffPfqlC6ryJq01Z1vRHCxcblAt9jV QCnA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yT/TJEKHboDAfIO6CXj+4CpRkzrNb91hKdAUUrheSj4=; b=TUn0hU9zvT4pEMQNOtopQB3r6TanDPdWbIEWkM/7vfht5cBWLcxHmA/wC0Fj8Jb4Ct vG5q0l9QslBGi0rTDePi3qyfODtnPeiwK/tIrnh9JoeTqg/bF9xdAIBZUutg1mnoCMEi K1Zn2adCE63phOam3r0WNkvqP77Ggjox+pQkUq7oUfPWxwSRHfOrP8VFdD7zfc65Ao53 oZP4zf8OOyA5G667zv3Gb+gUPn2He+8Q6tCsMBfPonaxGlEhhWz4BFrI9ha14fpAwlpk bqgf+z124OgsuAgsul1AqBu0eYlrCRKMI4SP2cHL+EQ6HbcomK2wwAXbTScPFKE/DtpZ sFnw==
X-Gm-Message-State: AGi0PuYVQQJE4RvumzFTj9+/XEKtrm2Xx/NjA/QsfmbMhQ17zKaWLizT seSQqxtJFXEuiDCWBdmUsgs3tMpu/Z5lyd4v0+4=
X-Google-Smtp-Source: APiQypJt2Dwmn9kIiTWJZd1Tsm0mD5U8VNjTU6o7jKoNriSgqgLbG7Woi2NRt6FiqO3sng+gddLk9v7U7/TIpNrAinU=
X-Received: by 2002:a2e:9456:: with SMTP id o22mr21414410ljh.94.1588172216746; Wed, 29 Apr 2020 07:56:56 -0700 (PDT)
MIME-Version: 1.0
References: <CAGWHT=YHzJTafq7yk2KSMLdy5oFw=O4K+Xru+=C7d_by+WT5ow@mail.gmail.com> <632020ED-4708-4AD7-9F4A-069E294CA5B7@vigilsec.com> <8aaa80ca-9da0-784e-a1fa-9f7ce039abb1@nthpermutation.com> <CAGWHT=ZxiM313TNkv1sbo_COw9o=-nCz1qeFeRHMxvjOpm0oZw@mail.gmail.com>
In-Reply-To: <CAGWHT=ZxiM313TNkv1sbo_COw9o=-nCz1qeFeRHMxvjOpm0oZw@mail.gmail.com>
From: Peter Bowen <pzbowen@gmail.com>
Date: Wed, 29 Apr 2020 07:56:45 -0700
Message-ID: <CAK6vND_v3ALiJqV_uA-QRCE0S5fZCPKU8KxDf1gN-Rae4ydaog@mail.gmail.com>
To: Tom Hans <tomhans18@gmail.com>
Cc: "<pkix@ietf.org>" <pkix@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/WynxkI_UbRlzqmoYQmeWtxYAdJE>
Subject: Re: [pkix] technical question about RFC 6960
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: Wed, 29 Apr 2020 14:57:01 -0000

On Tue, Apr 28, 2020 at 11:17 PM Tom Hans <tomhans18@gmail.com> wrote:
>
> Hello,
>
> thank you for your answers.
>
> I know that the OCSP response cannot be validated because I do not have the Root CA B installed.
> If I do this the response is validatable.
>
> What I like to know is if this is RFC conform?
> In RFC 6960 section 4.2.2.2. there are mentioned the following three possibilities:
>
>    1. Matches a local configuration of OCSP signing authority for the
>       certificate in question, or
>
>    2. Is the certificate of the CA that issued the certificate in
>       question, or
>
>    3. Includes a value of id-kp-OCSPSigning in an extended key usage
>       extension and is issued by the CA that issued the certificate in
>       question as stated above.
>
>
> Point 2 and 3 are not used because the certificate in request is issued by Root CA A and point one is not really clear for me.

There are two different architectures here.  Points two and three
cover "first party" status checking - asking the issuer of the
certificate or someone authorized by the issuer to tell you the
status.  Point on covers "third party" status checking - asking an
unrelated party about the certificate.

Comparing this to the process of driver's licenses in the US, you can
ask the state government department or agency that issues licenses
about the status of a license.  That is point 2.  You could also ask a
police department about the license and also ask the police for a
certificate that they are authorized to provide license status.  That
is point 3.  However a license is also frequently used as
identification.  A private club could have a membership list.  You
could ask the club secretary whether license matches someone on the
membership list.  It doesn't necessarily tell you that the person is
authorized to drive a car, but they can tell you if the person is
authorized to enter the clubhouse.  That is point 1.

You hit a OCSP responder that is covered under point 1.  Unless you
have out of band knowledge that the answers it is providing are
relevant to your use case, then having B tell you about status of
things A issues probably is not what you want.

Thanks,
Peter