Subject: [Anima] WG Last Call on draft-ietf-anima-bootstrapping-keyinfra-15

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 May 2018 03:56:08 +0200

Dear ANIMA WG,

After thorough review and discussions on the mailing list and in bootstrap
meetings, leading to the -15 version the authors and WG chairs think the draft
is now mature enough for working group last call.

This e-mail starts a two-weeks period for evaluation of this document by the WG.

Please provide your feedback on the ANIMA mailing list by end of June 14th, 2018.

Thanks and best regards

Toerless (for the ANIMA chairs).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 May 2018 14:52:57 +1200

I can answer quickly. Apart from the minor point in my previous
message, I believe that the GRASP part of this is correct,
and I have exercised it in the latest versions of my demo code
(Reggie.py, Procksy.py and Pledji.py at https://github.com/becarpenter/graspy).

(They were created for the -12 draft but I believe they still apply
to -15.)

I have no issues with the rest of the draft, but I'm not a security expert.

Regards
   Brian

On 31/05/2018 13:56, Toerless Eckert wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 May 2018 08:56:17 +0200

I have reviewed the document and we have a PoC.  I am also aware of
others that have done PoC code. I am not aware of any issues.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 May 2018 20:43:47 +0200

Thanks, Eliot

Good point, forgot to ask/mention this point in my previous emails.

As an ANIMA contributor, i would love for a draft/->RFC like BRSKI to
mention known existing implementations, especially open source, even if just PoC. 

But i have no idea if and/or how thats seen to be appropriate by IETF
standards. Traditionally i think it was not done, but then again,
with the amount of focus (not to say hype ;-) the IETF does around
open source and hackathons, it almost sounds absurd to me not to mention such code.

I am only aware of github.com/cisco/libest, but would love to see
any known code be mentioned. Single sentence with references to
appropriate URLs to those implementations would suffice IMHO.

What do others think/know about BCP in IETF protocol RFC re such mentioned of known code ?

(i know, there can be implementation experience drafts/RFC later on as
 well, but i think that's an independent, more in-depth effort.)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 May 2018 20:48:18 +0200

> What do others think/know about BCP in IETF protocol RFC re such mentioned of known code ?

I don't mind that pointer being listed, though we should *always* check
with the code developers before doing so.  In this case we can check
with them to be sure.

The 2nd piece of code is not open source and not by Cisco.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 May 2018 21:13:48 +0200

> The 2nd piece of code is not open source and not by Cisco.

If you can propose text/reference (as necessary after contacting authors) for
either, that would be lovely!

Cheer
    toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Jun 2018 08:48:18 +1200

This should be in a special section "Implementation Status [RFC Editor: please remove]" according to RFC7942/BCP0205. We have such a section in draft-ietf-anima-grasp-15.

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 17:51:10 -0400

> mention known existing implementations, especially open source, even if just PoC. 

IDs have included Implementation Reports during ID phase.
That section has usually been removed prior to publication, but perhaps not
always. Why not ask a friendly AD?
{My feeling is that including an implementation reports in a Draft Standard
is confusing DS with Internet Standard, and results in the bar being
informally raised. }

    > appropriate URLs to those implementations would suffice IMHO.

https://minerva.sandelman.ca/
https://github.com/AnimaGUS-minerva

Contains a MASA called "highway" (in Ruby on Rails), a JRC called "fountain"
(also in Ruby in Rails), a Pledge simulator called "reach".  They all use
a library called Chariwt, which started it's life being about CWT signing
vouchers, but now does COSE, JOSE and CMS signing of JSON and CBOR format
vouchers.

In addition to be able to download the code, there are two MASA "live" on the
Internet, see:
    https://minerva.sandelman.ca/metasite/2017/10/25/jokeshop-setup.html

The idea is that you can "purchase" a unit by downloading a public/private
keypair, embedding that into your "product", and when it enrolls to your
JRC, there will be a MASA (in nonce audit mode) that will answer. Once the
unit has become owned, then the MASA removes if from the available inventory,
and cons' up another keypair.

The libest folks have set all of them up and tried to interoperate, but
last I heard, they were a few IDs behind in the code, and I hadn't heard a
more recent statement of the situation.

In addition. the JRC devel branch currently has DTLS+CoAP code being added.
The change to move the existing CoAP code to have DTLS underneath it was
not easy, as the OpenSSL DTLS code has some problems in it's DTLS API.
(At least, I say it does, and I did patches for it. I can't get my patches
upstream until I find a VAX to test compile them on though...)

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 17:58:13 -0400

Brian E Carpenter <[email-masked]> wrote:
   > This should be in a special section "Implementation Status [RFC Editor:
   > please remove]" according to RFC7942/BCP0205. We have such a section in
   > draft-ietf-anima-grasp-15.

I question the value of adding that section during WGLC.
okay, it might sit in mis-ref for a few more months, which might help
someone.   Is it that useful to the IESG?

Having said that, I don't have any problem adding it, I just don't want to do
much work on it :-)

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Jun 2018 13:14:07 +1200

> I question the value of adding that section during WGLC.

Supposedly, it helps the IETF as a whole and the IESG evaluate
the document, which is the stage after WGLC.

   Brian