Re: [Sidrops] proposed, revised text for Section 6

George Michaelson <ggm@algebras.org> Tue, 05 May 2020 01:15 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF75C3A12C7 for <sidrops@ietfa.amsl.com>; Mon, 4 May 2020 18:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.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 NSRpOHF23eS6 for <sidrops@ietfa.amsl.com>; Mon, 4 May 2020 18:15:33 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (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 B403D3A133A for <sidrops@ietf.org>; Mon, 4 May 2020 18:15:29 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id y26so673671ioj.2 for <sidrops@ietf.org>; Mon, 04 May 2020 18:15:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+qvv5cAWKN5VaGhzXOC17rPa0LDBTYzbQVacwrFDIk0=; b=cDpUp8ulOGhRxWykK9egbUh2L7/4xtzfLMnbTNRezEE4BX8re5EnUBkV5Aadi6+jcC bpeZOL1zcpDKczD5pfTaet9XDLD0YQ4aYJR0qZHeVH/pdGSX6KxsGtWMgQrBMQOZbV3p Mx6/k+5g7yNSxpW41+PZRpK/UCbkpHjpamS3zBv4AV+O9FcJR6u9B62Bx2CXhabJEESK +iAmEITwqo9A7SS7e4KBCYuTmFY9gvM1Hlr3a6z1U5a1mjqQJYIfymLxjORZzNd7Bd0k zPMldHLg07NWnoIY1FsOaDd7kg+RRApiEC55CYzyIxUpXpjTKhdNe9FPIpdeOEam0Est B53w==
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:content-transfer-encoding; bh=+qvv5cAWKN5VaGhzXOC17rPa0LDBTYzbQVacwrFDIk0=; b=sLhJ02GdOYPnZg91gbEWKqW/gaIeDvJ8W4h8iz508pUWTz2lglNtOpMGOkga3VvPVl OnQoGaco/27iTM75ZP0pZUQKoXlOI1ICz6CvgKfKuaz+yRizI685DmP7BACiVQWxD/nZ BwWZo4qCavBM7I9IKqjBNcVEBI78bj3i8J7+XbXJG26iwoCnO9+4WGeMrNzsFPcR2FR6 iNHXB9yRwnwWKqwDO5O80RBXL4ZyjE4lluVzXtbI1yDh+ln3nLHaFyBjZf29Cos40Idh iw2VhZdqV/hXJAS6KIF9Ss+3obK9cNY8t3HjgT54HQkRNlBJqGmAYnPIZNW3ooQKVP4i EsKA==
X-Gm-Message-State: AGi0PuaMdr/1jz3f+8BKTWQPjvcTcQ9Nr4TbU5/egbwNSotmc40q+aWt 6kPqsCiz6JuZc9NhWc4xVl2VEhGc3BXKP4fxDlYKPUKF
X-Google-Smtp-Source: APiQypI6FPZUXHKUFpHsJvOuE1WxVTphfZEaqKGsQhEYKlz8HHmDbx/KR8GvhY3VS3d4YAma3MMXITwUIs7atOfEUAw=
X-Received: by 2002:a02:40c2:: with SMTP id n185mr1196822jaa.43.1588641328320; Mon, 04 May 2020 18:15:28 -0700 (PDT)
MIME-Version: 1.0
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
In-Reply-To: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net>
From: George Michaelson <ggm@algebras.org>
Date: Tue, 05 May 2020 11:15:16 +1000
Message-ID: <CAKr6gn29namLq5qq6WhhveT+6r7vC8W9SmwPcNP_un93GWmP9A@mail.gmail.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7074BYQKpmONcEZG8-rU3kQollQ>
Subject: Re: [Sidrops] proposed, revised text for Section 6
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2020 01:15:36 -0000

I just want to note that while I think you made a logically consistent
choice, I do not agree with its intent, in as much as I believe cached
state could be used to construct the valid state which the manifest
and CRL declare.

So, I think you drove to a harder place than I intended. But, I accept
this is a choice, and a strong choice.

I suspect I am in a minority of one on this. I would not seek to
impede a group decision driving to a more narrow constrained
definition.

-George

On Tue, May 5, 2020 at 6:09 AM Stephen Kent
<stkent=40verizon.net@dmarc.ietf.org> wrote:
>
> To get the discussion going, I generated the following text for Section 6. I deleted anything that was not definitive (e.g., deferred to local policy) and removed the warning message suggested text (I assume RP software developers can write their own messages, but we can add this back if folks feel it's useful.
>
> I also added a paragraph about the manifest/CRL circular relationship.
>
> In all cases I adopted the approach George suggested, i.e., if there's an error indicating that one or more signed objects may be missing (or not current), ignore ALL data associated with the CA instance at the pub point and DO NOT rely on cached data.
>
> Comments welcome, as usual.
>
> All new text is in red.
>
> Steve
>
> -----
>
>
>
> 6.1. Determining Manifest State & Object Acceptance
>
>
>
>    For a given publication point, and given CA instance, an RP MUST perform
>
>    the following tests to determine the manifest state of the publication
>
>    point. (Note that, during CA key rollover [RFC6489], signed objects for
>
>    two or more different CA instances will appear at the same publication
>
>    point. The tests described below are to be performed for a specified CA
>
>    instance, i.e., a the manifest’s EE certificate was issued by that CA.)
>
>
>
>    1. Select the CA's current manifest (the "current" manifest is the
>
>        manifest issued by this CA  having the highest manifestNumber among
>
>        all valid manifests (as defined in Section 4.4).
>
>
>
>       If the publication point does not contain a valid manifest, proceed
>
>       as described in Section 6.2. (Lacking a valid manifest, the following
>
>       tests cannot be performed.)
>
>
>
>    2. Check that the current time (translated to UTC) is between
>
>       thisUpdate and nextUpdate.
>
>
>
>       If the current time does not lie within this interval, proceed
>
>       as described in Section 6.4.
>
>
>
>
>
>   3. Acquire all objects at the publication point associated with this
>
>      CA instance, i.e., the CRL and each object containing an EE
>
>      certificate issued by the CA. If there are files listed in a manifest
>
>      that do not  appear at the publication point, then proceed as
>
>      described  Section 6.5.
>
>
>
>
>
>    4. Verify that the listed hash value of every file listed in the
>
>       manifest matches the value obtained by hashing the file at the
>
>       publication point.
>
>
>
>       If the computed hash value of a file listed on the manifest does
>
>       not match the hash value contained in the manifest, then proceed
>
>       as described in Section 6.6.
>
>
>
>    5. If a current manifest contains entries for objects that are not
>
>       within the scope of the manifest, then the out-of-scope entries
>
>       MUST be disregarded in the context of this manifest.  If there
>
>       is no other current manifest that describes these objects within
>
>       that other manifest's scope, then see Section 6.2.
>
>
>
>
>
>    Note that there is a “chicken and egg” relationship between the
>
>    manifest and the CRL for a given CA instance. If the EE certificate
>
>    for the manifest is revoked, the CA or publication point manager has
>
>    made an error. In this case all signed objects associated with the CA
>
>    instance MUST be ignored. Similarly, if the CRL for the CA instance
>
>    is not listed on a valid, current manifest, all signed objects
>
>    associated with the CA instance MUST be ignored, because the CRL is
>
>    missing.
>
>
>
>
>
> 6.2.  Missing Manifests
>
>
>
>    The absence of a current manifest at a publication point could occur
>
>    due to an error by the publisher or due to (malicious or accidental)
>
>    deletion or corruption of all valid manifests.
>
>
>
>    When no valid manifest is available, there is no protection against
>
>    attacks that delete signed objects or replay old versions of signed
>
>    objects. To guard against the adverse impact of processing an
>
>    incomplete set of signed objects, an RP MUST treat all signed objects
>
>    associated with the missing manifest as invalid. (These objects are
>
>    all issued by the same instance of a CA.) RP software MUST issue a
>
>    warning when there is no current manifest for a CA instance.
>
>
>
>    An RP may have access to a local cache containing a previously
>
>    issued manifest that is still valid. It is RECOMMENDED that the RP
>
>    not make use of this data, to ensure consistent a consistent outcome
>
>    in when a manifest is missing.
>
>
>
> 6.3.  Invalid Manifests
>
>
>
>    The presence of an invalid manifest at a publication point could
>
>    occur due to an error by the publisher or due to (malicious or
>
>    accidental) corruption of a valid manifest.  An invalid manifest MUST
>
>    never be used, even if the manifestNumber of the invalid manifest is
>
>    greater than that of other (valid) manifests.
>
>
>
>    If there is no valid, current manifest available at the publication
>
>    point for the CA instance, an RP MUST treat the signed objects at the
>
>    publication point as indicated above in Section 6.2. A warning MUST
>
>    be issued when an invalid manifest is encountered.
>
>
>
> 6.4.  Stale Manifests
>
>
>
>    A manifest is considered stale if the current time is after the
>
>    nextUpdate time for the manifest.  This could be due to publisher
>
>    failure to promptly publish a new manifest, or due to (malicious or
>
>    accidental) corruption or suppression of a more recent manifest.
>
>
>
>    All signed objects at the publication point issued by the entity that
>
>    has published the stale manifest, and all descendant signed objects
>
>    that are validated using a certificate issued by the entity that has
>
>    published the stale manifest at this publication point, MUST be
>
>    treated at invalid and a warning MUST be issued.
>
>
>
>    The primary risk in using such signed objects is that a newer
>
>    manifest exists that, if present, would indicate that certain objects
>
>    have been removed or replaced.  (For example, the new manifest might
>
>    show the existence of a newer CRL and the removal of one or more
>
>    revoked certificates).  Thus, the use of objects from a stale
>
>    manifest may cause an RP to incorrectly treat invalid objects as
>
>    valid.  The risk is that the CRL covered by the stale manifest has
>
>    been superseded, and thus an RP will improperly treat a revoked
>
>    certificate as valid.
>
>
>
>
>
> 6.5.  Mismatch between Manifest and Publication Point
>
>
>
>    If there exist valid signed objects associated with a CA instance and
>
>    they do not appear in any current, valid manifest for this CA instance,
>
>    these objects MUST be ignored by an RP, and a warning MUST be issued.
>
>
>
>    If there are files listed on the manifest that do not appear in
>
>    the repository, then these objects have been improperly deleted from
>
>    repository (via malice or accident).  A primary purpose of manifests is
>
>    to detect such deletions.  Therefore, in this case, an RP MUST ignore
>
>    all signed objects associated with this CA instance.
>
>
>
> 6.6.  Hash Values Not Matching Manifests
>
>
>
>    A file appearing on a manifest with an incorrect hash value could
>
>    occur because of publisher error, but it also may indicate that an
>
>    attack has occurred, e.g., one in which an older version of an object
>
>    has been substituted for a newer version of the object. In this case
>
>    an RP cannot know the content of the missing object, and thus all
>
>    signed objects associated with this instance of the CA MUST be ignored
>
>    by the RP, and a warning MUST be issued.
>
>
>
>
>
>
>
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops