Subject: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Thu, 11 Jul 2019 06:20:38 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. Despite comments/DISCUSSes raised, this was a good
read.

1) In Section 5:

   o  In the language of [RFC6125] this provides for a SERIALNUM-ID
      category of identifier that can be included in a certificate and
      therefore that can also be used for matching purposes.  The
      SERIALNUM-ID whitelist is collated according to manufacturer trust
      anchor since serial numbers are not globally unique.

I think now you are just inventing things. Please define what exactly
SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed.

2) In 5.6:

   assertion:  The method used to verify assertion.  See Section 5.5.5.

Section 5.5.5 doesn't define syntax of this field in enough details to
implement. Can it contain one of the allowed values (like C enum)?

3) In 5.8

   This is done with an HTTP GET using the operation path value of
   "/.well-known/est/requestauditlog".

Here you say to use HTTP GET.

   The registrar SHOULD HTTP POST the same registrar voucher-request as

But you only define how to use POST. I think the first "GET" is supposed to be
"POST".

4) In 5.8.1:

Format of different fields is not defined, so this is not interoperable.

5) In 8.1:

   This document extends the definitions of "est" (so far defined via
   RFC7030) in the "https://www.iana.org/assignments/well-known-uris/
   well-known-uris.xhtml" registry as follows:

   o  add /.well-known/est/requestvoucher (see Section 5.5 )

   o  add /.well-known/est/requestauditlog (see Section 5.7)

The .well-known URIs IANA registry doesn't list anything below the first level
(i.e. "est" in your case). So I think you really want to have 2 IANA actions
here:

a) Add the reference to this document as another reference for "est".

b) create a new registry of "est" URIs and add your 2 URIs above to it and also
populate other entries from the original EST RFC.

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

The first mention of HTTP 1.1 needs a Normative reference.

1.5.  Requirements for Autonomic Network Infrastructure (ANI) devices

   Upon successfully validating a voucher artiface, a status telemetry
   MUST be returned.  See Section 5.7.

"artiface" is an unfortunate typo. I think you meant "artifact" here.

In 2.3.2:

   As explained in [RFC5280] section 7.4, a complete IRI SHOULD be in
   this extension, including the scheme, iauthority, and ipath.  As a
   consideration to constrained systems, this MAY be reduced to only the
   iauthority, in which case a scheme of "https://" and ipath of
   "/.well-known/est" is to be assumed, as explained in section
   Section 5.

This is not a problem per se, but mixing absolute URIs and iauthority in the
same field makes me rather uncomfortable. Maybe you can define ABNF for this
field to make it crystally clear what is allowed here. This would also avoid
the need to use SHOULD and MAY above.

In 2.3.2: "https" URI scheme needs a Normative reference.

2.7.  Cloud Registrar

   If the pledge uses a well known URI for contacting a cloud registrar
   an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
   authenticate service as described in [RFC6125].

Just referencing RFC 6125 is not clear enough, as there are lots of parameters
that need to be specified:

 a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
 b) are wildcards allowed in any of these?

4.  Proxying details (Pledge - Proxy - Registrar)

   In order to permit the proxy functionality to be implemented on the
   maximum variety of devices the chosen mechanism SHOULD use the
   minimum amount of state on the proxy device.

What does this mean? How can compliance with this SHOULD be evaluated? I think
you want to use lower case "should" here.

In 5.7 (and a similar issue elsewhere):

   {
     "version":"1",
     "Status":FALSE /* TRUE=Success, FALSE=Fail"

This is not valid JSON, this is not even valid pseudo-JSON. Please move the
comment:

 TRUE=Success, FALSE=Fail

After this block to avoid confusion. Please add missing "," after each
attribute value

     "Reason":"Informative human readable message"
     "reason-context": { additional JSON }
   }

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Jul 2019 19:52:16 -0400

> SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed.

https://github.com/anima-wg/anima-bootstrap/issues/132
I've asked Max to respond to this issue.

    > implement. Can it contain one of the allowed values (like C enum)?

I agree. We seem to have lost the definition.
We insert an new section after 5.5.5 that explains this.
https://github.com/anima-wg/anima-bootstrap/issues/133

    > But you only define how to use POST. I think the first "GET" is
    > supposed to be "POST".

Fixed.

    > Format of different fields is not defined, so this is not

We think that they are, as they are either repeats of what was in the
voucher, or are integers.  I guess we should resort to CDDL, which, since we
started this document, is now a thing.
https://github.com/anima-wg/anima-bootstrap/issues/134

    > The .well-known URIs IANA registry doesn't list anything below the
    > first level (i.e. "est" in your case). So I think you really want to
    > have 2 IANA actions here:

    > b) create a new registry of "est" URIs and add your 2 URIs above to it
    > and also populate other entries from the original EST RFC.

The advice we got from the .well-known expert was that we should have this
document Updates: RFC7030, and that the /est entry in the registry
should say "RFC7030, RFCXXXX".  Will this be enough rather than create
a new registry?  We think that no other /.well-known has a registry.

Tell us which way to go.

    > The first mention of HTTP 1.1 needs a Normative reference.

Added.

    > "artiface" is an unfortunate typo. I think you meant "artifact" here.

Already fixed.

    > "/.well-known/est" is to be assumed, as explained in section Section 5.

    > This is not a problem per se, but mixing absolute URIs and iauthority
    > in the same field makes me rather uncomfortable. Maybe you can define
    > ABNF for this field to make it crystally clear what is allowed
    > here. This would also avoid the need to use SHOULD and MAY above.

Adam complained that we were using IRI inappropriately, so I'll wait for his
response before changing this part.  I don't think we need ABNF.  Our goal is
to put as short a thing in the certificate as possible.
hostname:port is enough as the rest can be defaulted by the JRC.
However, we observe the need to override the entire thing, particularly when
doing interop testing, and so we want to be able to put the entire URL/IRI
in.

    > In 2.3.2: "https" URI scheme needs a Normative reference.

added reference to 7230, section 2.7.3

    > Just referencing RFC 6125 is not clear enough, as there are lots of
    > parameters that need to be specified:

    >  a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed b) are wildcards
    > allowed in any of these?

We think it's up to the manufacturer to define a policy here.
This section is an out for manufacturers that wish to provide some call-home
mitigation for when the device is deployed where no ACP can be found.
Maybe saying "well known URI" is causing a mis-understanding?

    > maximum variety of devices the chosen mechanism SHOULD use the minimum
    > amount of state on the proxy device.

    > What does this mean? How can compliance with this SHOULD be evaluated?
    > I think you want to use lower case "should" here.

Agreed.

    >    { "version":"1", "Status":FALSE /* TRUE=Success, FALSE=Fail"

    > This is not valid JSON, this is not even valid pseudo-JSON. Please move
    > the comment:

Already fixed, please see changes at:
   https://tinyurl.com/y2ex324x

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Jul 2019 20:14:05 -0400

If you visit the URL I gave to Eric:
   https://tinyurl.com/y2ex324x

you will get an RFCDIFF that is rather wide.
One of the fixes is for the very long JSON in the example in the appendix,
so the left side is very very wide.

The -22 version is very wide, which is rather annoying, so you have to scroll.
I may post a -23 version with a fix for ONLY the wide JSON, so that
a diff against -24 is more understandable.  I can't do that until
22nd, but perhaps I'll stage it elsewhere until then.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 13 Jul 2019 21:05:19 -0400

This is an RFCDIFF that just wraps the very-long JSON:

https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-22&url2=https://www.sandelman.ca/tmp/dtbootstrap-anima-keyinfra-22B.txt

This is an rfcdiff from the already-wrapped JSON to the proposed -23 that
includes all the changes from the various DISCUSSes:
  https://tinyurl.com/y2qhjwh8

This does not suffer from being very very wide.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jul 2019 13:12:54 -0400

> SERIALNUM-ID is. Cut & paste text from RFC 6125, if needed.

https://github.com/anima-wg/anima-bootstrap/commit/2f4cee70fc583c60a4589c983043a346ac0145ea

new text reads:
        This extends the informal set of "identifer type" values defined in
        <xref target="RFC6125" /> to include a SERIALNUM-ID
        category of identifier that can be
        included in a certificate and
        therefore that can also be used for matching
        purposes. As noted
        in that document this is not a formal definition as
        the underlying
        types have been previously defined elsewhere. The
        SERIALNUM-ID whitelist is collated
        according to manufacturer
        trust anchor since serial numbers are not globally
        unique.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 18 Jul 2019 17:02:11 +0100

Hi Michael,

> a new registry?  We think that no other /.well-known has a registry.

I think the answer depends on whether you want to have an easy way of finding second level URI path components under "est". I personally prefer a new registry, but I understand that it might be a bit more work in the document.

> Maybe saying "well known URI" is causing a mis-understanding?

On a re-read, the current text looks Ok as is.

Best Regards,
Alexey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Thu, 18 Jul 2019 17:06:06 +0100

Hi Michael,

>         trust anchor since serial numbers are not globally

This is actually not helping. I was looking for something like:

  DNS-ID = a subjectAltName entry of type dNSName

Basically I was asking for a definition of SERIALNUM-ID somewhere.

Best Regards,
Alexey

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Jul 2019 19:30:10 -0400

Alexey Melnikov <[email-masked]> wrote:
    >> > o In the language of [RFC6125] this provides for a SERIALNUM-ID >
    >> category of identifier that can be included in a certificate and >
    >> therefore that can also be used for matching purposes.  The >
    >> SERIALNUM-ID whitelist is collated according to manufacturer trust >

    > Basically I was asking for a definition of SERIALNUM-ID somewhere.

It's a (subject)DN of serial number=123456, not a subjectAltName.
(not the CertificateSerialNumber)

It's X.520.. via 802.1AR and RFC5280 section 4.1.2.4.
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.520-201610-I!!PDF-E&type=items
section 6.2.9.

    o  Client authentication is automated using Initial Device Identity
       (IDevID) as per the EST certificate based client authentication.
       The subject field's DN encoding MUST include the "serialNumber"
-      attribute with the device's unique serial number.
+      attribute with the device's unique serial number as explained in
+      Section 2.3.1
 
-   o  This extends the informal set of "identifer type" values defined
-      in [RFC6125] to include a SERIALNUM-ID category of identifier that
-      can be included in a certificate and therefore that can also be
-      used for matching purposes.  As noted in that document this is not

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 18 Jul 2019 19:31:09 -0400

Alexey Melnikov <[email-masked]> wrote:
    >> The advice we got from the .well-known expert was that we should have
    >> this document Updates: RFC7030, and that the /est entry in the
    >> registry should say "RFC7030, RFCXXXX".  Will this be enough rather
    >> than create a new registry?  We think that no other /.well-known has a
    >> registry.
    >> 
    >> Tell us which way to go.

    > I think the answer depends on whether you want to have an easy way of
    > finding second level URI path components under "est". I personally
    > prefer a new registry, but I understand that it might be a bit more
    > work in the document.

I prefer Updates: 7030.

---

From: "Alexey Melnikov" <[email-masked]>
Date: Fri, 19 Jul 2019 12:36:45 +0100

> (not the CertificateSerialNumber)

In this case, you need to use CN-ID as the base for the definition. The important part there is that the RDN can't be repeated multiple times in a DN. If it does, that would make the whole DN not suitable for use a la RFC 6125.