Re: [pkix] technical question about RFC 6960

Tom Hans <tomhans18@gmail.com> Thu, 30 April 2020 06:57 UTC

Return-Path: <tomhans18@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 B13D03A0997 for <pkix@ietfa.amsl.com>; Wed, 29 Apr 2020 23:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 3C1myN7ETCGT for <pkix@ietfa.amsl.com>; Wed, 29 Apr 2020 23:57:47 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 D53ED3A0995 for <pkix@ietf.org>; Wed, 29 Apr 2020 23:57:47 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id a32so321391pje.5 for <pkix@ietf.org>; Wed, 29 Apr 2020 23:57:47 -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; bh=6gw72K2JNC24Dzv1+uC9GnoDOAmjIvhiUaMUq7qpsUA=; b=VqulYIGpiXAcR4kMLKBH9A+HZUqPcGnXS/woMUm5hdGDY2vymAfo0YcrsHY5rId10y pOgQolk/00PhctyQSHO3EgEyy1XKoGaTaauEIxz9AktB/tOiigwcVyoagSV0vxXrHj0x pH++Z4/YFiR9fcXds6wsaCSjLkpuwHayBxVPTSgtJEnmi3/4Nylan2dZHQAtqTP2oj+B 77eZiAop3q0L//kUrFqJf0C2ugdjFhYGO4g40/MMZKSodUnt2/SAj2WHVkZD6033tnQq hAt65i+/r06B+3n+Na6fSA0y87t3hVB293ZLUvjc/Wk47+tHbinnc1HkN/IIv3/ogRBc Rykw==
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; bh=6gw72K2JNC24Dzv1+uC9GnoDOAmjIvhiUaMUq7qpsUA=; b=pKgrGj1Ml2TrPYQL2ZICvZ/gpcsv5KIUS4Lrjz/iNlJlAgy+SR7PYxZeFl6FPZeveA P38F6Z8bR73sIbahwa5Rh1Y/Kpt/ODNRSRL075thdRCnKMiXhEe53oI8Vd4/pyUiGjFI qoPRBh6JIohEPdcQyFn6WEHeEOfWzwwo6jStktovj2kzzxxWL2bGC3q/0xpK7U3lFRfL ScHHGi8JNpmJReL1uw5K6EpKDOD6j8qCwMZiVmwrducUB2nALKKH3xXSStMP2qab7TbR AvvX/UaD3kNP6LN1YDK614jxEyQzJndBm4Tk9eHlbhglmslt/ScYtOBHVlck7eCDfit2 wdcA==
X-Gm-Message-State: AGi0PuY97/2tp+V6/Lp30wYq+a+g6yH/eOM+5ngv4gEMxrt7F7ywuekN t0+vWLpXWYdzSleWE39WtW4yufM1BF4K05bytBRz45q1
X-Google-Smtp-Source: APiQypLxuCARTKj36Fd/b0Q6AabKj4ieFVIHIYf6AS/Qd0dd4e+RO80fuPgR9MZMkDkJcpHi5KytFayiOon5S8dbHq0=
X-Received: by 2002:a17:90a:23e2:: with SMTP id g89mr1311833pje.105.1588229867149; Wed, 29 Apr 2020 23:57:47 -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> <CAK6vND_v3ALiJqV_uA-QRCE0S5fZCPKU8KxDf1gN-Rae4ydaog@mail.gmail.com>
In-Reply-To: <CAK6vND_v3ALiJqV_uA-QRCE0S5fZCPKU8KxDf1gN-Rae4ydaog@mail.gmail.com>
From: Tom Hans <tomhans18@gmail.com>
Date: Thu, 30 Apr 2020 08:58:09 +0200
Message-ID: <CAGWHT=Yha2tmbb-VmDfbZs6sc8R5FzzfVpTU=DEV8BKJM1ExwQ@mail.gmail.com>
To: pkix@ietf.org
Content-Type: multipart/alternative; boundary="0000000000000d9bb405a47c95e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/SrNsPZ-pntQvAJCSGvVhMQlhSf0>
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: Thu, 30 Apr 2020 06:57:50 -0000

@Russ
The AIA extension of EndCert A contains:
[1]Authority Info Access
     Access Method=Certification Authority Issuer (1.3.6.1.5.5.7.48.2)
     Alternative Name:
          URL=https://pki.spi-cloud.com/issuer
[2]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp.spi-cloud.com/status/
RI:http://ocsp.spi-cloud.com/status/


@Peter thank you for your explanation. This helps a lot :)
So the only "out of band" knowledge I would have is that I saw the signer
through Wireshark nothing else.
Consequently this is a bad behavior of the CA itself.

Am Mi., 29. Apr. 2020 um 16:56 Uhr schrieb Peter Bowen <pzbowen@gmail.com>:

> 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
>