Re: [pkix] [Technical Errata Reported] RFC5280 (7164)
Carl Wallace <carl@redhoundsoftware.com> Fri, 14 October 2022 23:23 UTC
Return-Path: <carl@redhoundsoftware.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 90A96C14CE34 for <pkix@ietfa.amsl.com>; Fri, 14 Oct 2022 16:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.86
X-Spam-Level:
X-Spam-Status: No, score=-0.86 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw_vCxC-uROV for <pkix@ietfa.amsl.com>; Fri, 14 Oct 2022 16:23:20 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000ACC14CE38 for <pkix@ietf.org>; Fri, 14 Oct 2022 16:23:19 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id l28so4648352qtv.4 for <pkix@ietf.org>; Fri, 14 Oct 2022 16:23:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=mime-version:in-reply-to:references:thread-topic:message-id:cc:to :from:subject:date:user-agent:from:to:cc:subject:date:message-id :reply-to; bh=GburvQmZuEjgUcZgyCmNrT/Sg7CFkWR3wMjjkjm0O9M=; b=j0zzw0ZOP+QKRRwl4xgTVQ32gA0tc+0J6D78hTOw86tXc2OaFz/Du6AheJ2DIOeS/3 lTIsn4no0ctkWf7PUe5U+U7Pl7o9SNaf5J5ANDJ1kAvLFj8U4nOEzP2n3P3qu0xRkvJn kdUCmuwqWJuF9jBvLIfd7K8T8sCdaAghC098I=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:in-reply-to:references:thread-topic:message-id:cc:to :from:subject:date:user-agent:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=GburvQmZuEjgUcZgyCmNrT/Sg7CFkWR3wMjjkjm0O9M=; b=Y5SJGqtmHCEf0bDGnZ9afLMkM6naZNnM8K3yi+hQPWkS4QOUSXm3LkzRHS+w1GYIzB zJudv0jfLh5+bYQspTlMaKxJQI8bmSOGlk9qrLVX7kkQgcvwWvAVJEsKYeWslejj3Z/n y4R1ONJHwnN0RlvCk91wFec+UOclaipXgv8r+93V7VM9JO4t7aW+LZrVHop3S+Ti+w70 Zx9iy/cdEgRNTYIKToqjB3qZO4xnJhuyZF1lz7dSfRz0B56Eb9iwLarbhgwiyoeGAI6m xvuPuHgb78/Yk2m8i3iGkBWSWYRoaANvvubCvALsVtNGtrPH6kFPYdWQtNSZO3JY2Ija hYtw==
X-Gm-Message-State: ACrzQf0B//k8HZOTa486YO2BUFtKL80iEhCiXlgewC6Gf8YF+q/Tij4P hq6US9ls8xNINrO087RnJw7lzw==
X-Google-Smtp-Source: AMsMyM6sA6PmZblGU5GXhe1KkIdprfv+gSSVjd9ryG1S3ibhqcj9zraVoTAeU64T9HqEl9Zjh1JGLQ==
X-Received: by 2002:ac8:594d:0:b0:35c:ba75:c1dc with SMTP id 13-20020ac8594d000000b0035cba75c1dcmr155120qtz.286.1665789798754; Fri, 14 Oct 2022 16:23:18 -0700 (PDT)
Received: from [192.168.2.16] (pool-74-96-253-253.washdc.fios.verizon.net. [74.96.253.253]) by smtp.gmail.com with ESMTPSA id y10-20020a37f60a000000b006e2d087fd63sm3256726qkj.63.2022.10.14.16.23.18 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 14 Oct 2022 16:23:18 -0700 (PDT)
User-Agent: Microsoft-MacOutlook/16.66.22101101
Date: Fri, 14 Oct 2022 19:23:17 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org>, "David A. Cooper" <david.cooper@nist.gov>
CC: RFC Errata System <rfc-editor@rfc-editor.org>, pkix@ietf.org
Message-ID: <43D80D51-F005-4E63-9002-588A64A9EF6F@redhoundsoftware.com>
Thread-Topic: [pkix] [Technical Errata Reported] RFC5280 (7164)
References: <20221014193934.45A8855E27@rfcpa.amsl.com> <f0316f70-a901-1683-8345-8798f702c85b@nist.gov> <CAEmnErd3LMav5amb_nf+QZza1K85AvOqghMQvTSvH8set5m6cQ@mail.gmail.com>
In-Reply-To: <CAEmnErd3LMav5amb_nf+QZza1K85AvOqghMQvTSvH8set5m6cQ@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3748620198_1141399231"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/lkSGnXVuNERb1BUiAqAfWg26tkg>
Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (7164)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 14 Oct 2022 23:23:24 -0000
If the proposed fix were accepted, what would be included in a CRL that included an IDP extension with the distributionPoint field absent and the onlyContainsCACerts field set to true? From: pkix <pkix-bounces@ietf.org> on behalf of Aaron Gable <aaron=40letsencrypt.org@dmarc.ietf.org> Date: Friday, October 14, 2022 at 7:14 PM To: "David A. Cooper" <david.cooper@nist.gov> Cc: RFC Errata System <rfc-editor@rfc-editor.org>, <pkix@ietf.org> Subject: Re: [pkix] [Technical Errata Reported] RFC5280 (7164) Ah, interesting. I agree that the distributionPoint URL does not seem necessary in cases where the CRL contains extensions which fully describe its scope and inclusion in a scope which can be computed based on fields of the certificate itself. For example, a CRL with a crlScope extension with a serialNumberRange indicating that it contains entries for certificates with even-numbered serials is not vulnerable to substitution attacks because a relying party can compute whether or not the certificate in question falls within the scope of the CRL. But Section 5 explicitly allows CRLs to have scopes which cannot be encoded using the issuingDistributionPoint, crlScope, or AAissuingDistributionPoint extensions, such as "all certificates issued to the NIST employees located in Boulder". And, of course, the crlScope extension was already deprecated by the time X.509 (08/2005) was published, removing the ability of even a CRL with a scope like "all even-numbered serials" to be representable within the CRL itself. This leads me to believe that the intent of this requirement was to ensure that all sharded/partitioned/scoped CRLs should have a distributionPoint to defend against substitution attacks. However, the actual text of the requirement, via its inclusion of the "within its scope" qualifier, fails to convey that intent. That is why I suggested this errata in this location. Aaron On Fri, Oct 14, 2022 at 1:17 PM David A. Cooper <david.cooper@nist.gov> wrote: I believe that this errata is incorrect. The text from RFC 5280 that is proposed to be modified is referring to the distributionPoint field of the issuingDistributionPoint extension, whereas the text that is quoted from X.509 is referring to the issuingDistributionPoint extension as a whole. X.509 is noting that if there is no extension limiting the scope of the CRL, then the scope of the CRL must be all unexpired public-key certificates issued by the CRL issuer. The extension limiting the scope could be the issuingDistributionPoint extension or it could be some other extension (e.g., crlScope or AAissuingDistributionPoint). The text from Section 5.2.5 of RFC 5280 is about the case in which the issuingDistributionPoint extension is present, but the distributionPoint field in that extension is absent, in which case the scope of the CRL is presumably limited by some other field in the issuingDistributionPoint extension. The submitter may be correct that RFC 5280 never explicitly says that the scope of a CRL must include all unexpired certificates issued by the CRL issuer unless the CRL contains an extension (or extensions) that limit the scope, but addressing that would involve a different change from the one proposed here. On 10/14/22 12:39 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5280, > "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile". > > -------------------------------------- > Type: Technical > Reported by: Aaron Gable <aaron@letsencrypt.org> > > Section: 5.2.5 > > Original Text > ------------- > If the distributionPoint field is absent, the CRL MUST contain > entries for all revoked unexpired certificates issued by the CRL > issuer, if any, within the scope of the CRL. > > Corrected Text > -------------- > If the distributionPoint field is absent, the CRL MUST contain > entries for all revoked unexpired certificates issued by the CRL > issuer. > > Notes > ----- > The removed phrase does not appear in the original text that this requirement is derived from, ITU-T Rec. X.509 (08/2005) Section 8.6.2.2: "If the issuing distribution point field, the AA issuing distribution point field, and the CRL scope field are all absent, the CRL shall contain entries for all revoked unexpired public-key certificates issued by the CRL issuer." > > The removed phrase does not serve to create a stricter requirement; rather it creates a looser requirement which allows a CRL which does contain entries for all revoked unexpired certificates *within its scope* to not include the distributionPoint field. Given that the distributionPoint field serves an important security purpose in preventing substitution attacks, it is unlikely that this loosening was the intent of the original authors. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5280 (draft-ietf-pkix-rfc3280bis-11) > -------------------------------------- > Title : Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile > Publication Date : May 2008 > Author(s) : D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk > Category : PROPOSED STANDARD > Source : Public-Key Infrastructure (X.509) > Area : Security > Stream : IETF > Verifying Party : IESG _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix
- [pkix] [Technical Errata Reported] RFC5280 (7164) RFC Errata System
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… David A. Cooper
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Stefan Santesson
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Aaron Gable
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Carl Wallace
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Aaron Gable
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Carl Wallace
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Russ Housley
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… David A. Cooper
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Tim Hollebeek
- Re: [pkix] [Technical Errata Reported] RFC5280 (7… Carl Wallace