Re: [lamps] draft-ietf-lamps-8410-ku-clarifications: EE/CRLIssuer Text

Jonathan Hammell <jfhamme.cccs@gmail.com> Fri, 03 June 2022 18:25 UTC

Return-Path: <jfhamme.cccs@gmail.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B47C14F74E for <spasm@ietfa.amsl.com>; Fri, 3 Jun 2022 11:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn75WfGhEO7Z for <spasm@ietfa.amsl.com>; Fri, 3 Jun 2022 11:25:10 -0700 (PDT)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 A2B7AC14F725 for <spasm@ietf.org>; Fri, 3 Jun 2022 11:25:10 -0700 (PDT)
Received: by mail-vs1-xe31.google.com with SMTP id c62so8098096vsc.10 for <spasm@ietf.org>; Fri, 03 Jun 2022 11:25:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=aJt1oPOcUIY6jp5eMMJGKfKcfkUKIi9c5d990NAGmEY=; b=X0BIS1YhNKo6u423PMKt+YM+f2Y9YjH2if8RRnv2HB0QAW7180b9ag7Y1YYwQQUKlV q/RRyumOIkpusN8xYah48XVYKfn2hg1bXw/EU2A7wPJ7GGNoaGOjKYjU0SeTI8ovDEQr oUpteWbnXSsoPzYkmebjU1XMJqEH9LYFPhh3uPI88J8zVa8BQXBT0mfy6oD/p2iZGYE8 QaRtgp6v69tGSfMxKSw9GbSLg2AdBaekpxcW4qfkASZ0uBoyCfRzEM8iIKlBL45Ewyg+ OJAZZya5zNn0MhBaXgOgr3pDgwLdMiR2DxiqtVS3W9gHvRQtPylha9J0bnKaFY5Iv84h Tq3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=aJt1oPOcUIY6jp5eMMJGKfKcfkUKIi9c5d990NAGmEY=; b=hoMtmFQWiZ/Wb30mQ9/lEzOYc3uEd28h3WLMwrR+UwXvSvEKNgUNdgeJV+g01haelj Te2DKnHcvs7//da1NLke8AA28rCQ2vyikVPUAGPpSLVpHHvRVmekrgmG1PdKdClUDNIx LXlXux02AtbuRD309xIx49aOqMes13W1xf08Ef9olg1DHvDeXVUwtcyT3h+I3M+bKOAA UhZtzNIBsEmZLKomq6jLjBF/FBpBDwszmaMcloWH1XveiyNzhEuwnKIxFZd2SbQtHWNq rDMl/jnmfRHifTTbsraKvwg55VnUItqibFqFZR37GX+1GUHRmqGJFx4kXgUVt/bIjH5p Hveg==
X-Gm-Message-State: AOAM531vKtv+3B+X7rmXOSEUYEVCU54NgCgJeCBS2yRw2jd/ppjZ8Wr/ 0HehZUDbTaughQoYw37QT/4a/SJqtoBQHM1CXZ0pY7BDCRcgyQ==
X-Google-Smtp-Source: ABdhPJxv+B8xT2p5wVyP3BemF+qk96xjxkh76qjYOiNLU8QNOjSZf4CBNK6+vUpk2T7fnzPY42O3QCYgsvYaVCMVwyc=
X-Received: by 2002:a67:f1c6:0:b0:34b:9509:28a with SMTP id v6-20020a67f1c6000000b0034b9509028amr2045210vsm.46.1654280709324; Fri, 03 Jun 2022 11:25:09 -0700 (PDT)
MIME-Version: 1.0
References: <1C2C3B94-DA30-4DA4-BBF3-F7F873587F30@sn3rd.com>
In-Reply-To: <1C2C3B94-DA30-4DA4-BBF3-F7F873587F30@sn3rd.com>
From: Jonathan Hammell <jfhamme.cccs@gmail.com>
Date: Fri, 03 Jun 2022 14:24:58 -0400
Message-ID: <CALhKWgha0RY880soan=jhfTL4FG0mrGhTrpBPvqkuLEvmQfmqg@mail.gmail.com>
To: Sean Turner <sean@sn3rd.com>
Cc: LAMPS WG <spasm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/7lc4qfrBDRALMT-OMTmKaFoGBJw>
Subject: Re: [lamps] draft-ietf-lamps-8410-ku-clarifications: EE/CRLIssuer Text
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jun 2022 18:25:11 -0000

Hi Sean,
I agree with separating the cases of end-entity certificates and CRL
issuer certificates.  However, the cRLSign bit should always be set in
the KeyUsage extension of a CRL issuer certificate.  I believe this is
implied in the following text of RFC 5280:

   If the keyUsage extension is present, then the subject public key
   MUST NOT be used to verify signatures on certificates or CRLs unless
   the corresponding keyCertSign or cRLSign bit is set.

Therefore, aligning with the text for certification authority
certificates, the following might be more clear for the CRL issuer
case:

If the keyUsage extension is present in a CRL issuer certificate that
indicates id-Ed25519 or id-Ed448 in SubjectPublicKeyInfo, then the
keyUsage extension MUST contain:

  cRLSign;

and zero or more of the following:

  nonRepudiation;
  digitalSignature; and
  keyCertSign;

and the following MUST NOT be present:

  keyEncipherment;
  dataEncipherment;
  keyAgreement;
  encipherOnly; and
  decipherOnly.

...

Note that this allows keyCertSign for CRL issuer certificates, which
seems to be implied by the certification authority certificate text in
the I-D allowing cRLSign.

Best regards,
Jonathan

On Thu, Jun 2, 2022 at 9:06 AM Sean Turner <sean@sn3rd.com> wrote:
>
> Hi! During IESG review we got comments from a couple of couple of ADs (3) about EE/CRL issue text (note this is NOT a DISCUSS but if we tripped up 3 then it’s probably worth having a look at):
>
>    If the keyUsage extension is present in an end-entity or CRL issuer
>    certificate that indicates id-Ed25519 or id-Ed448 in
>    SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
>    least one of the following:
>
>      nonRepudiation;
>      digitalSignature; and
>      cRLSign;
>
> and the following MUST NOT be present:
>
>      keyEncipherment;
>      dataEncipherment;
>      keyAgreement;
>      keyCertSign;
>      encipherOnly; and
>      decipherOnly.
>
> One way to fix this is to make the following changes to separate out the EE and CRL issuer:
>
>    If the keyUsage extension is present in an end-entity
>    certificate that indicates id-Ed25519 or id-Ed448 in
>    SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
>    least one of the following:
>
>      nonRepudiation; and
>      digitalSignature;
>
> and the following MUST NOT be present:
>
>      keyEncipherment;
>      dataEncipherment;
>      keyAgreement;
>      keyCertSign;
>      encipherOnly; and
>      decipherOnly.
> ….
>
> Also ADD:
>
>    If the keyUsage extension is present in an CRL issuer
>    certificate that indicates id-Ed25519 or id-Ed448 in
>    SubjectPublicKeyInfo, then the keyUsage extension MUST contain at
>    least one of the following:
>
>      nonRepudiation;
>      digitalSignature; and
>      cRLSign;
>
> and the following MUST NOT be present:
>
>      keyEncipherment;
>      dataEncipherment;
>      keyAgreement;
>      keyCertSign;
>      encipherOnly; and
>      decipherOnly.
>
> Open to other suggestions as well.
>
> Cheers,
> spt
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm