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
- [pkix] technical question about RFC 6960 Tom Hans
- Re: [pkix] technical question about RFC 6960 Russ Housley
- Re: [pkix] technical question about RFC 6960 Michael StJohns
- Re: [pkix] technical question about RFC 6960 Tom Hans
- Re: [pkix] technical question about RFC 6960 Russ Housley
- Re: [pkix] technical question about RFC 6960 Peter Bowen
- Re: [pkix] technical question about RFC 6960 Tom Hans
- Re: [pkix] technical question about RFC 6960 Russ Housley
- Re: [pkix] technical question about RFC 6960 Tom Hans
- Re: [pkix] technical question about RFC 6960 Russ Housley