Re: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)

Alvaro Retana <> Wed, 16 October 2019 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5AD5120086; Wed, 16 Oct 2019 15:09:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.736
X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Cx0zK-gV5tLT; Wed, 16 Oct 2019 15:09:51 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD1C612004A; Wed, 16 Oct 2019 15:09:50 -0700 (PDT)
Received: by with SMTP id c4so55629edl.0; Wed, 16 Oct 2019 15:09:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=watnlkCovFLjSRKzm0LzZY9sB0S+H0/UE9uiP89TZoU=; b=aa5g2RTsHW4T0dxC8TQk1u9po3KTWIMN6BgJlVa56h0oXUTcFy8tWBJUM3qH9GQKRZ XOYUV7iNVCXcPwK2j/UDlE/PKFFVgAqRNihHY+1nmCSNxOHTj3Vdnx3TK6CY26iI3soA rA/711h18P0Xyus6DCq7JM7oq++iG7vpKBG0SYDphTRINwyru/Vav8y+1T/sC3YyGbXG yL3cnjx4mlxxa9fr7dBoSNq8BTEeqm3c2XtYOr9SNbgCrzrBq20oErDNGf0NryIhvpgK rkS21rBM8WpTP5QgdhOxvHkiY8rK3W+qvQRXmGtorwiZRWu79gr2koGgx3aSvHfwuz70 YUfA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=watnlkCovFLjSRKzm0LzZY9sB0S+H0/UE9uiP89TZoU=; b=NFCAzDLFyZ53JCXf5+mEdVOZHbKaSnHWoWQXsRlqbBiKjlhr6fVAMdw5ryGhJIUyzD 9p+jjtC7GfhKc3I0rPxfTKceCCLKHirGIHtOk95p/nCSgRRUJI48LYaj0AR5xmvKXKQH HTqV6g2d3wj7Om84+dlNOREwTdOr5tBpWNK+f0jBVZWnR0oE7A0fgRQtQ5nP1Yne8wUs /vHe2I5Yqwjcqxldzlmn1ARzFi6atnPwWTYM6HbVL5edg1awBo5lJS5DXzPINOKHAI2X K2fT2rVyDvFbEiUuXTLDRonTUGTuPJsKKVbJw3Wjep0cBT9AlsxK9YCAcbbWqZ8F7pu3 1jjg==
X-Gm-Message-State: APjAAAVgr79whmzwdn8Kft2JTgyOdGz0ogOl8Ik2+jQlowG6sNRMiG9e OYdYf3fcsTvXcsVMfdTz6srTRIVEtKcH3A2BSVg=
X-Google-Smtp-Source: APXvYqxkLGlmCST+rp4l17AU/RlVQFgeU7RYnItDcSD745PiuzclV8Rx8YeZQ2c/PDeNGJK0rXUUfwPjZ7bggxNv/MQ=
X-Received: by 2002:a17:906:cd11:: with SMTP id oz17mr552549ejb.71.1571263789293; Wed, 16 Oct 2019 15:09:49 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 17 Oct 2019 00:09:48 +0200
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Thu, 17 Oct 2019 00:09:48 +0200
Message-ID: <>
To: Michael Richardson <>
Cc:,, Toerless Eckert <>, The IESG <>,
Content-Type: multipart/alternative; boundary="00000000000002636e05950e5c1c"
Archived-At: <>
Subject: Re: [Anima] Alvaro Retana's No Objection on draft-ietf-anima-bootstrapping-keyinfra-28: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Oct 2019 22:09:53 -0000

On October 16, 2019 at 5:34:13 PM, Michael Richardson (



> (3) s/The serialNumber fields is defined in [RFC5280], and is a SHOULD
field in
> [IDevID]./The serialNumber field is defined in [RFC5280], and is a
> field in [IDevID]. Note that SHOULD is not used properly here because it
> not have a Normative quality (as it refers to the other document). I'm
> assuming that the replacement is "recommended" (per rfc2119), but it may
> "required".

802.1AR says it is SHOULD. We need to increase this to MUST.
RECOMMENDED is a synonym for SHOULD according to 2119.
REQUIRED is a synonym for MUST, so if I changed it to REQUIRED then it would

still be a problem according to your thinking...?

So I could reword as:

IDevID certificates for use with this protocol are REQUIRED to
include the "serialNumber" attribute with the device's unique
serial number (from [IDevID] section 7.2.8, and [RFC5280] section's list of standard attributes).

which might be an easier read. Please let me know if I am mis-understanding

The original text sounded as if you were characterizing the field specified
in rfc5280.

The new text specifies that the serialNumber MUST be there.  If that is
what you meant from the start, then I’m ok with it. :-)