{to reply to an old email with some valid questions, and some questions of my
own. I am also clipping the reply-To}Panos Kampanakis (pkampana) <[email protected]> wrote: > I am curious about your workflow in > https://www.ietf.org/mail-archive/web/6tisch/current/msg05020.html You > are envisioning for the JCE to initiate the bootstrapping to the > pledge, but wouldn't that better be defined in the > anima-bootstrapping-keyinfra doc? Constrained bootstrap is not really in scope for ANIMA. The general constrained bootstrap situation is too big, but 6tisch constrains the possible solution space, which is why we feel that we can make progress there. So, I want to accomodate constrained bootstrap in anima-bootstrap, but not define it. > About 'simple system that can be used with PSKs as authentication', I > was curious. Did you have TLS-PSK, or TLS-SRP or OSCOAP message auth > with PSK/RPK/Cert? Anything more detail about these usecases? This is being proposed as 6tisch-minimal-security, and it uses OSCOAP and EDHOC. > A nit in " <--- CoAP POST /cert----- [PKCS7 Certificate] ". That > message would require the private key to be included with the cert > since the pledge did not generate it by himself. EST defines CMS for > this message. PKCS12 could suffice here as well with the challenge if > the passphrase provisioning being the problem. I'm not sure I understand this. Why do you say that the pledge did not generate it by himself? I"m assuming that it did so at manufacturing time, and that an IDevID certificate was bound to the public part of the key. -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
