Re: [pkix] [Technical Errata Reported] RFC5280 (7164)

Aaron Gable <aaron@letsencrypt.org> Fri, 14 October 2022 23:33 UTC

Return-Path: <aaron@letsencrypt.org>
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 147CDC14CE34 for <pkix@ietfa.amsl.com>; Fri, 14 Oct 2022 16:33:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.433
X-Spam-Level:
X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, 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=letsencrypt.org
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 Ex4dKIyUtr3l for <pkix@ietfa.amsl.com>; Fri, 14 Oct 2022 16:33:47 -0700 (PDT)
Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 4863FC14CE45 for <pkix@ietf.org>; Fri, 14 Oct 2022 16:33:42 -0700 (PDT)
Received: by mail-ua1-x932.google.com with SMTP id h25so2462696uao.13 for <pkix@ietf.org>; Fri, 14 Oct 2022 16:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=V7EMbTXsbocvmkLAp4qijMhRDZlrtFgZ5mdz1C6bV1I=; b=fRgieB/YYgAidbKXKreE2SpOXV1Ui0tOMXVm2clAoNC04ZRL6owy7OhE5AeesuV6Gq vkzPLAerWGy3AoG5dcSbq/PMln+OJAQJqvpTJHxVspMHjNGtD+xOE3173ymFYxrc6478 EJeE56OGtgs4mj8/bNWpx871zI4ND7FghfSyQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=V7EMbTXsbocvmkLAp4qijMhRDZlrtFgZ5mdz1C6bV1I=; b=tDulvNPQKZM63aMCFK3FBTDhplO6qarB5WD97OkgWYV8JF5NNqlPWudTOZ8AlC2kVQ G5somuO8TQQi/UC15Vgz65V8oCsowoaLRloi1uPRAJbcy8KEYC1/rw9PiN2P1HEnZRh5 KTwh4r9GgMFuuODO8bH8S3io+U9ZBxyeDGJgnS8OJzOaNa1Bb9qCMl5dRlxLg/e87kcM RhEdKGCyQL9bZkt5Mc1Mkc0blBQqhJdW1XzVw+T1cA0IOIt0vuJ/wvkEeTAaODCFhD0l cbFc+lGkkF9Binrqx0zxqPPvrDQycFtpsA84isFQyjOp0nDtYuXFbkx41NmrxiMoDjnu JNMw==
X-Gm-Message-State: ACrzQf1Ydh5ltaPYjZUQ7fwBqQYKprLFygH41jh/wQ0hFNisjZiCQxOJ yZMPTKPUHg9fXI/tcZ4Yof9//40YWBX+pFlTvkd51A==
X-Google-Smtp-Source: AMsMyM5/ByMUhlV6CfVxMqjiq3HV/yBAHxofjhHtSn4CQuZalPPfQma+MEzjdG7DOb/wNw/KHgf3lfgLU0edr8Ed3cQ=
X-Received: by 2002:a05:6130:64c:b0:390:f639:5ac4 with SMTP id bh12-20020a056130064c00b00390f6395ac4mr66372uab.98.1665790421243; Fri, 14 Oct 2022 16:33:41 -0700 (PDT)
MIME-Version: 1.0
References: <20221014193934.45A8855E27@rfcpa.amsl.com> <f0316f70-a901-1683-8345-8798f702c85b@nist.gov> <CAEmnErd3LMav5amb_nf+QZza1K85AvOqghMQvTSvH8set5m6cQ@mail.gmail.com> <43D80D51-F005-4E63-9002-588A64A9EF6F@redhoundsoftware.com>
In-Reply-To: <43D80D51-F005-4E63-9002-588A64A9EF6F@redhoundsoftware.com>
From: Aaron Gable <aaron@letsencrypt.org>
Date: Fri, 14 Oct 2022 16:33:30 -0700
Message-ID: <CAEmnErcoA8=zZxWsgq8CgmS-NeNiWkmub4roRKO2TLqkdPEsJw@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Cc: "David A. Cooper" <david.cooper@nist.gov>, RFC Errata System <rfc-editor@rfc-editor.org>, pkix@ietf.org
Content-Type: multipart/alternative; boundary="00000000000054299905eb070e91"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/tIYOAQSOu2Ywej8MSed6HNEcGQ0>
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:33:53 -0000

The CRL would contain entries for all revoked unexpired certificates issued
by the CRL issuer. It would also be asserting that the CRL issuer does not
issue any end-entity public key certificates, and therefore that all
certificates issued by the CRL issuer are CA certificates. If this
assertion were not true, the CRL would be considered misissued.

I think this interpretation is reasonable, given that the conditionality of
the requirements around the distributionPoint field and the requirements
around the onlyContainsCACerts field are opposites. The former says "if
this field is missing, then something must be true", while the latter says
"if something is true, then the field must be present". It does not matter
*why* that condition is true -- perhaps the scope only contains CA certs
because the CA has decided that should be the scope, or perhaps the scope
only contains CA certs because the issuer has in fact only issued CA certs
-- the consequence of the condition being true is the same either way.

Aaron

On Fri, Oct 14, 2022 at 4:23 PM Carl Wallace <carl@redhoundsoftware.com>
wrote:

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