Subject: [6tisch-security] getting closer on draft

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Apr 2014 18:42:06 -0400

I posted an -02, still very very very drafty draft:
  datatracker.ietf.org/doc/draft-richardson-6tisch-security-architecture/?include_text=1

diff: http://goo.gl/1Eygjs

I've been hitting writers block for three weeks trying to get the ideas down
clearly, and finally I realized that I needed to stop worrying about the
mechanism by which the certificate chains are carried, and focus on them.

I have to go back and re-read the 802.1AR document to make sure that I use
the right terminology.  I found draft-pritikin-bootstrapping-keyinfrastructures-00
to be in many ways too general... it's an architecture, and making some
choices is what the 6tisch security needs.

The steps that bootstrapping-keyinginfrastructure are either named wrong, or
I don't understand them, because I think that I've shoved it all into step
two, and you see I have little beyond that.   Please advise.

I don't agree with section 5.2 of that document.  It has the new entity
responsible for joining, and maybe that is appropriate for some uses, but
for constrained systems, I think that the Registrar should be responsible for
obtaining/creating a new certificate for the New Entity.

One realization this afternoon was that the TLS as used by EAP-TLS is
backwards to our needs, while if we use the simpler DTLS/COAP method that
leverages 6top, there are no identity problems.

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Apr 2014 18:46:35 -0400

Michael Richardson <[email-masked]> wrote:
    > The steps that bootstrapping-keyinginfrastructure are either named
    > wrong, or I don't understand them, because I think that I've shoved it
    > all into step two, and you see I have little beyond that.  Please
    > advise.

okay, I know. I don't know like 4.3.3's dependancy upon the MASA.
While going online to a MASA to claim devices is okay, and the token is
appropriate, I don't want to depend upon that.  It should be possible to
receive a USB key, floppy disk, QR code/etc. containing a set of certificates
that prove that ACME Widgets owns the new devices.