IETF Logo Mail Archive

Re: [pkix] technical question about RFC 6960

Michael StJohns <msj@nthpermutation.com> Tue, 28 April 2020 18:37 UTC

Return-Path: <msj@nthpermutation.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 77DFD3A03ED for <pkix@ietfa.amsl.com>; Tue, 28 Apr 2020 11:37:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=nthpermutation-com.20150623.gappssmtp.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 r8_RCFtpfbBg for <pkix@ietfa.amsl.com>; Tue, 28 Apr 2020 11:37:15 -0700 (PDT)
Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 BA25F3A1AC4 for <pkix@ietf.org>; Tue, 28 Apr 2020 11:36:47 -0700 (PDT)
Received: by mail-qk1-x735.google.com with SMTP id n143so22866200qkn.8 for <pkix@ietf.org>; Tue, 28 Apr 2020 11:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=JKx8Jv86bqL8P74mYLR/KY1D+MqzWPIAA1N5pV0O4bc=; b=d6Y/+8hgZNlwvkuCnvYl497S1pPeDWbt5ZQjlqSVUfKKWnnMxy2SvOZWbxJ0twLFDe H/g10AFDar0V1iNLKYzfLtcrz7U07rUxcsUaiPs3iyQ9rxZKYUe9C+zgwQplW1JcFCjb LIwo8xHPXhqXbjrbRaFRjaBpssMf9JlQoEMba8e1LWmv0e79+w9x9OxPRBYut8WZQex+ f0B7sQEC/3W8RL9mMq3DslQWMMVZmu9KHFOVq+rOLBPGLwLPtLu5boOSQq551XwVntDM ROrfiSQ4VEisFu10snTaGdGds33apdDnkPgvr1iNdQeUqyL94uIqFd2rG1Atx28MCAc7 QqVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=JKx8Jv86bqL8P74mYLR/KY1D+MqzWPIAA1N5pV0O4bc=; b=sz4xwBgtJ7ZPxiIMEoDMqgOkByDil/ETK8FsvqKUGAkIeY7VE27DoP4dfb35xhmC7L HtNfulKxnTayZB2UsqPI+B+mVmqfLTo+jKdonb2OhZ6TFyyhn1iVGsx8Zik3vniuWfUg 3xHSUDoMbo4r58iGVgleBVtf2UxSk30+IpOUEFfaRNN/pdF4zo+q9uQL8z4LOHPcxwmK pHgnvtlMbKir7hGk8ByrNwCMi5uyMiyikOfK8l/KYIGwCDhcM2MBnVSZpTEJY+K7gjnu vCj6tszla9L9J/cIHxcibFewQmWhotIvX5Z9c7Xsceves2mLt2g1GT5WzhvXJS2anNb0 KfVw==
X-Gm-Message-State: AGi0PubHAcmgVMzfN283aaQ/imeT4ijVtNuC8Kb7vo1QzsHrRUOndDUC DakRNuHshJW2R+RHhqqOvGzTmvSVWAX3+Q==
X-Google-Smtp-Source: APiQypLDffcRkogCIEDitOVKbLgkWQd6qxHsXM48QiRk2PvgaWtZfvn10AomS2LcdNelWjQDxKXfMQ==
X-Received: by 2002:a05:620a:c8c:: with SMTP id q12mr28689071qki.74.1588099006362; Tue, 28 Apr 2020 11:36:46 -0700 (PDT)
Received: from [192.168.1.115] (pool-71-163-188-115.washdc.fios.verizon.net. [71.163.188.115]) by smtp.gmail.com with ESMTPSA id g2sm10701022qkm.0.2020.04.28.11.36.45 for <pkix@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Apr 2020 11:36:45 -0700 (PDT)
To: pkix@ietf.org
References: <CAGWHT=YHzJTafq7yk2KSMLdy5oFw=O4K+Xru+=C7d_by+WT5ow@mail.gmail.com> <632020ED-4708-4AD7-9F4A-069E294CA5B7@vigilsec.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <8aaa80ca-9da0-784e-a1fa-9f7ce039abb1@nthpermutation.com>
Date: Tue, 28 Apr 2020 14:36:45 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <632020ED-4708-4AD7-9F4A-069E294CA5B7@vigilsec.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/AueEeyUOLW2K7w98uGJl4xUBGPo>
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: Tue, 28 Apr 2020 18:37:20 -0000

I'm also assuming from the description that you don't actually have a 
trust anchor (e.g. Root CA B) for the B chain installed and my guess is 
that's ultimately the problem leading to the OCSP check failing.   Mike


On 4/28/2020 1:43 PM, Russ Housley wrote:
> OCSP provides the status of one certificate.  So, two OCSP queries are needed in path A, one for the Intermediate A, and another for EndCert A.  The AIA extension in each of these certificates tells where to send the query.  I assume from the short description that you provided that at lease one of the AIA extensions is pointing to EndCert B as the OCSP responder.
>
> Russ
>
>
>> On Apr 28, 2020, at 10:33 AM, Tom Hans <tomhans18@gmail.com> wrote:
>>
>> Dear Ladies and Gentlemen,
>>
>> I was forwarded from the IETF Secretariat to this mailing list. I hope you can help me.
>> Currently I have some technical issues regarding to RFC 6960 and maybe I just misunderstand the described standards.
>> Therefore I kindly like to ask if someone could help me to understand if the scenario below is RFC conform or not.
>>
>> I hope you will help me.
>>
>> Kind regards,
>> Tom Hans
>>
>>
>>
>> Scenario:
>> We have the following certificate chains given:
>> Root CA A -> Intermediate A -> EndCert A
>> Root CA B -> EndCert B
>>
>> Now I check the revocation status of EndCert A using Windows certutil or Linux openssl with OCSP.
>> If the full chain of EndCert A is existing I can send a valid OCSP request and get an OCSP response which contains "good".
>> But even if the response contains "good" Windows and openssl tells me that the OCSP check is not good.
>> And here is the interesting Part:
>> The OCSP response is signed with the EndCert B and I do not see any kind of context between the two certificate chains. Moreover the response only contains the EndCert B and does not deliver the Root CA b which is not existing on my test environment.
>> So in no case it would be possible to check EndCert B for validity.
>> If I check the RFC 6960 I get stuck with 4.2.2.2.  Authorized Responders and I think it is not allowed to sign the OCSP response with EndCert B.
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

v2.23.0 | Report a Bug | By Email