Re: [6tisch] xxx-bootstrap

[Göran Selander <[e-mail]>]

Apologies for the previous empty mail, this is the mail I wanted to
comment on.

On 2016-12-01 01:18, "6tisch on behalf of Michael Richardson"
<[e-mail] on behalf of [e-mail]> wrote:

>
>Hi, I haven't read the entire thread yet, but I wanted to pull out another
>email from a private thread about some ideas I had before I forgot.
>
>This would be the phase 1.  Now that I understand more about EDHOC,
>I think that the certificate exchange and EDHOC setup would occur
>at the GET /nonce phase.
>
>Peter, if this is what you have in mind, then let's develop one of the
>EST/CoAP drafts into saying this.
>
>====
>
>I am thinking about if we can come up with a mechanism that can be driven
>by
>either side, which uses the same protocol and message encodings.
>I had been thinking last night that CMS was getting in the way, but I
>think that actually that's probably not the case; we are going to use
>pkcs7/11 anyway, and if that's really the extent of it, then no big deal.
>
>I'm trying to find a way to merge this into netconf-keystore essentially,
>and
>that document is not really particular about the formats.
>
>I'm looking at draft-ietf-anima-bootstrapping-keyinfra-04 section 5.7,
>and EST section 4.
>
>I imagine that one can reverse the process in 6tisch, and we could POST
>From the JCE to client /cacerts, etc...
>
>So, if the straight EST process looks like:
>
>    new-node                     registrar
>         POST /requestaudittoken-->     [includes nonce]
>         <--- 200 OK + audit token-     [section 5.2]
>
>         GET /cacerts ----------->
>         <--- domain certificate--     (application/pkcs7-mime,
>                                        CMC Simple PKI RESPONSE)
>         GET /csrattrs ---------->
>         <--- app/csrattrs -------     [ASN as per 7030]
>
>         POST /simpleenroll------>     (PKCS#10 Cert Req)
>         <--- LDevID cert---------     (pkcs7)
>
>
>Then the JCE driven process should instead look like:
>
>    pledge                       JCE
>         <--- CoAP GET /nonce-----
>         ----- 200 OK, nonce ---->     [could be empty if nonce
>
>         <--- CoAP POST /voucher--     {audit token or ownership voucher}
>         ----- 200 OK------------>     [or 4xx or 5xx code! ]


In the interest of reducing round-trips, could anything of this be sent in
parallel with the key exchange?

Göran




>
>         <--- CoAP POST /cacerts--     [block-transfer]  [maybe not??]
>                                       (application/pkcs7-mime,
>                                        CMC Simple PKI RESPONSE)
>         ----200 OK-------------->
>
>         <--- CoAP POST /csrattrs-     [ASN as per 7030]
>         ----200 OK-------------->
>
>         <--- CoAP GET  /csr------
>         ----200 OK ---PKCS10 ----     [PKCS#10 Cert Req]
>
>         <--- CoAP POST /cert-----     [PKCS7 Certificate]
>         ----200 OK --------------
>
>Except that ideally, the above would be described in YANG with Kent's help
>in netconf-keystore.
>(Pascal, in our SoW #7, the above protocol would be Deliverable 3, btw)
>
>
>
>--
>Michael Richardson <[e-mail]>, Sandelman Software Works
> -= IPv6 IoT consulting =-
>
>
>