Hi Michael,

all in favor of one approach to merge the push/pull aspects. (I have to understand the protocol exchange below, but it looks feasibale) I am not sure about understanding EDHOC, but may be that is not important.

I still see all the mime formats. is that phase 1?
Is phase 2 then switching to OSCOAP with a single format containing binary encoding?

cheerio, and thanks for your explanation.

Peter


Michael Richardson schreef op 2016-12-01 01:18:
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! ]

         <--- 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 <mcr+i...@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to