Subject: [saag] draft-hallambaker-mesh-udf-02

From: Michael Richardson <[email-masked]>
Date: Tue, 9 Apr 2019 13:37:23 -0400

Phill, I am reading your UDF document with the idea that IoT devices on
constrained networks can send a reference to an IDevID rather than send the
IDevID in-band.  This would apply to both DTLS and also to EDHOC and HIP
(such as for 802.15.9 keying).

I was reading section 1.2, and it says:

   The UDF EARL locator shown above is
   resolved by first determining the Web
   Service Endpoint for the mmm-udf service
   for the domain example.com. ¶

Discover ("example.com", "mmm-udf") =
https://example.com/.well-known/mmm-udf/
Next the fingerprint of the source UDF is obtained.

I was surprised that you went straight to http without a DNS SRV lookup.
This is a Greenfield, and adding that in seems like a good thing.

Okay, so section 6.2 includes text:
   The use of DNS Web Discovery permits
   service providers to make full use of the
   load balancing and service description
   capabilities afforded by use of DNS SRV and
   TXT records in accordance with the
   approach described in [RFC6763].

Maybe should mention this in section 1, or maybe just make the explanation
less authoritive sounding 8-;

Section 1.3 will need a forward reference.
I really like section 3.2.

application/pkix-keyinfo
I did not know this was a thing... Ah
 You are going to register it.

You have specified rfc3986 rather than 3987, so your URI are not
internationalized.  Is there a reason for that?

Can you advance the use document without the rest of mmm?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 22 Apr 2019 16:22:45 -0400

> (such as for 802.15.9 keying).

If we went down that route, we might want to go full throttle and add in a
code point for a verbatim public key rather than a hash of a public key. I
have added that to the spec and removed it three times because I do not
make use of it in the Mesh.

Another capability I left out is the authenticated only Locator form. So
the browser follows a link, gets back the result and compares the
fingerprint before accepting it. That could be a useful capability for
other applications.

Again, I left out features that I did not have an immediate use for but I
am mentioning them here to save people the bother of having to claim it in
a patent application like has happened to so much of my work in the past.
This was all discussed in the ni: uri work long ago.

I was reading section 1.2, and it says:
> This is a Greenfield, and adding that in seems like a good thing.

That would be a mistake I made in drafting.

I am very keen to use SRV/TXT as the service discovery mechanism
throughout. Not least because it is one of the techniques I hope to rely on
in the future to enable transport agility and to push security policy
constraints into the DNS.

> less authoritive sounding 8-;

Ack, yes. I should put a red flag there saying use SRV/TXT style resolution
(which is all that the referenced draft really does).

Agh... just realized where this issue originates from. It is actually due
to a bug in my RFC generator which means that references in examples were
mishandled. The example is in a markdown fragment I am pulling in from the
Word document... OK will get that fixed...

I will add one.

> I really like section 3.2.

Thanks!

> internationalized.  Is there a reason for that?

Lack of confidence in my knowledge of the subject material and lack of time
to get to a sufficient understanding.

Since the path-abempty of the URI is constrained to be base32 encoded text,
with punctuation (-/), the only place where there is scope for
internationalization is authority, that is the DNS name.

I have no objection to making it an ireg-name. But does that actually add
value?

If we are forming a QR code, we might as well just use the punycode.

The bit I am unclear on is 1) how widely deployed IRI support is and 2)
whether the applications simply treat URIs with an internationalized domain
name in the desired fashion anyway.

> Can you advance the use document without the rest of mmm?

Yes. I have presented the work as a single unit because this is what we
told the PeP people that we wanted when they came to SECDispatch. But I am
quite happy to go a-la-carte if people prefer.

The UDF doc is probably the one that is most easily separated from the rest
as it doesn't depend on any other part of the Mesh. It does depend
on draft-hallambaker-web-service-discovery but that is actually just a
profile of [RFC6763 <https://tools.ietf.org/html/rfc6763>] and [RFC5785
<https://tools.ietf.org/html/rfc5785>].

The other part that is (almost) standalone is DARE Container which is a way
to achieve blockchain type functionality in a JSON-friendly format without
the ideological baggage or assumptions that come from the crypto currency
world. DARE Container depends on UDF but doesn't require any other part of
the Mesh.

Another possibility is that people like the technology I am applying but
would prefer to look at extending PCKS#7/CMS and retrofitting these ideas
to other legacy protocols. I think it best to develop the capabilities
first and then look to how they might be retrofitted though. Conversion to
ASN.1 would require a sponsor willing to fund the work.

---

From: Nico Williams <[email-masked]>
Date: Mon, 22 Apr 2019 15:54:51 -0500

> ASN.1 would require a sponsor willing to fund the work.

It's all the same to me.  However, I would on balance prefer that a) no
new _encodings_ be created without b) a great deal of knowledge of what
came before.

I've been toying with this idea:

 - adapt the Heimdal ASN.1 compiler to output a JSON representation of
   the input module(s),

 - then use jq to transform that in various ways,

 - and lastly, use jq to generate codecs for the [transformed] module
   representations.

Interesting transformations would be to, e.g.,

 - apply code generation controls (e.g., "this INTEGER should be
   represented as a uint32_t in C, and that one as an in64_t"),

 - to add private structure fields for application use (for keeping
   state; this has been a significant driver for hand-coding of codecs).

Why jq?  Well, because it's a very pithy and accessible, functional,
high-level programming language specifically designed for working with
JSON data.  I would prefer to do the whole thing in Haskell, but I'm not
yet fluent in Haskell, and anyways, it's a less accessible language.

Of course, too, there's the fact that I'm one of the maintainers of jq,
which means I'm very familiar with it and productive in it.  But I have
a feeling that once I have a sample code generator for such a thing it
will be very easy to create new backends out of it -- in fact, that
would be a goal.

Nico
--

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Apr 2019 16:21:10 -0400

mcr>     Phill, I am reading your UDF document with the idea that IoT
    mcr> devices on constrained networks can send a reference to an IDevID
    mcr> rather than send the IDevID in-band.  This would apply to both DTLS and
    mcr> also to EDHOC and HIP (such as for 802.15.9 keying).

Phillip Hallam-Baker <[email-masked]> wrote:
    > If we went down that route, we might want to go full throttle and add
    > in a code point for a verbatim public key rather than a hash of a
    > public key. I have added that to the spec and removed it three times
    > because I do not make use of it in the Mesh.

I am not opposed to such a thing, but in my use case I would not use it.
I actually need the strong connection to the manufacturer, and the extensions
that PKIX provides. (Some new CoID would work equally well, but would also be
larger than a raw public key)

    > Another capability I left out is the authenticated only Locator
    > form. So the browser follows a link, gets back the result and compares
    > the fingerprint before accepting it. That could be a useful capability
    > for other applications. 

The fingerprint is in the link, along with the link?
That seems bigger, and does not help me.

    mcr>     You have specified rfc3986 rather than 3987, so your URI are not
    mcr> internationalized.  Is there a reason for that?

    > Lack of confidence in my knowledge of the subject material and lack of
    > time to get to a sufficient understanding.

    > Since the path-abempty of the URI is constrained to be base32 encoded
    > text, with punctuation (-/), the only place where there is scope for

I am also not an internationalization expert.
We referenced iauthority in 3987 in draft-ietf-anima-bootstrap-keyinfra
rather than authothority from 3986.  This is within a PKIX extension.
Maybe we were wrong.

    > If we are forming a QR code, we might as well just use the punycode.

Well that eats up a 30% more bytes, doesn't it?  It's not like we have to put
it through an ASCII<->EBCDIC gateway like email.

    mcr>     Can you advance the use document without the rest of mmm?

    > told the PeP people that we wanted when they came to SECDispatch. But I
    > am quite happy to go a-la-carte if people prefer.

    > The UDF doc is probably the one that is most easily separated from the
    > rest as it doesn't depend on any other part of the Mesh. It does depend
    > profile of [RFC6763] and [RFC5785].

Can we do that, then?

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