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

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Wed, 16 Oct 2019 08:19:07 -0700

Alvaro Retana has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-28: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) §1.3.2 (Constrained environments): "Those types of networks SHOULD NOT use
this solution."  The use of Normative language seems out of place: if this
document is not applicable to constrained environments, then there's no way to
enforce (SHOULD NOT)...   s/SHOULD NOT/should not

(2) §2.1: In Figure 2, should the "rejected" action be a result of step 3
(instead of 2)?

   |                   |
   |            +------v-------+
   |            | (2) Identity |
   ^------------+              |
   | rejected   +------+-------+
   |                   |
   |            +------v-------+
   |            | (3) Request  |
   |            |     Join     |
   |            +------+-------+
   |                   |

(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 recommended
field in [IDevID].   Note that SHOULD is not used properly here because it does
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 be
"required".

(4) [nits]

s/Bootstrapping to is complete/Bootstrapping is complete

§1: "This bootstrap process satisfies the [RFC7575] section 3.3 of making all
operations secure by default."  Satisfies the what?  Requirement, maybe?

s/explains the details applicability/explains the detailed applicability

s/out-of-band" information"/out-of-band" information

s/This section applies is normative for uses with an ANIMA ACP./This section is
normative for uses with an ANIMA ACP.

s/RFC XXXX: Manufacturer Usage Description Specification/RFC 8520: Manufacturer
Usage Description Specification

s/might be previous deployed/might be previously deployed

s/were receives by/were received from

s/{{...}}/[...]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 23:35:06 +0200

> enforce (SHOULD NOT)...   s/SHOULD NOT/should not

okay, fixed.

    > (2) §2.1: In Figure 2, should the "rejected" action be a result of step 3

The Pledge provides it's identity to the JRC at step 2.
(Effectively during the TLS setup)
If the JRC doesn't like (invalid manufacturer), then the TLS connection does
not complete.  It doesn't get to attempt to join.
If the voucher doesn't check out, then it's Enroll Failure.

    > assuming that the replacement is "recommended" (per rfc2119), but it may be

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
   4.1.2.4's list of standard attributes).

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

    > s/Bootstrapping to is complete/Bootstrapping is complete

Thanks.

    > operations secure by default."  Satisfies the what?  Requirement,

requirements, yes, thank you.

    > s/explains the details applicability/explains the detailed

thank you.

    > s/out-of-band" information"/out-of-band" information

fixed.

    > normative for uses with an ANIMA ACP.

fixed.

    > Usage Description Specification

I can't find that in -28, I think it was already fixed.

    > s/might be previous deployed/might be previously deployed

fixed.

    > s/{{...}}/[...]

Oh. markdown style infested the XML document.
I think this is my last .xml document.  At least, I hope.

Your changes in the diff:  https://tinyurl.com/y5l4xz3z

YANG doctor comments to come for -29, sometime after the RIPE IOT session
tomorrow.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alvaro Retana <[email-masked]>
Date: Thu, 17 Oct 2019 00:09:48 +0200

On October 16, 2019 at 5:34:13 PM, Michael Richardson ([email-masked])
wrote:

Michael:

Hi!

So I could reword as:

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

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. :-)

Thanks!

Alvaro.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Oct 2019 10:08:13 +0200

{fixing quoting. I had no idea what Alvaro wanted to say otherwise}

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

    mcr> 802.1AR says it is SHOULD. We need to increase this to MUST.
    mcr> RECOMMENDED is a synonym for SHOULD according to 2119.
    mcr> REQUIRED is a synonym for MUST, so if I changed it to REQUIRED then it would
    mcr> still be a problem according to your thinking...?

    mcr> So I could reword as:

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

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

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

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

So you prefer the reworded text, and I will use that in -29.