Michael StJohns <[email protected]> wrote: > Basically, the argument I'm hearing again is that we have to have > common protocols that work with the least capable devices in the same > way that they work with more capable devices. Which then is taken to > mean that we have to limit the security of said protocols to what's > available with those most limited devices.
This is not really what's going on here.
The argument is whether device generate private keys should be supported
in the constrained version of EST. The RA/CA (RFC5280 terms) side of things
in generally assumed not be seriously contrained.
(I expect to install a CA on an openwrt based Turris home router, but that's
equivalent to a 15 year old laptop, and hardly counts as constrained)
There is no reason why a RA/CA(%) can't support server-side key generation
according to RFC7030 section 4.4 as well as permitting capable devices to
generate their own keys.
Having the CA generate keys seemed to be all the rage at some point.
I was never clear if this was because desktop OSes couldn't be trusted
to do it properly, or because end-users wanted their private key as
part of their mobile profile, or because of the implicit escrow that it
permitted. (Remember splitting signing and encrypting keys...)
Panos' situation is, I understand, that he has customers with an extensive
deployment of devices in the field. They currently use a proprietary
enrollment and key distribution system. They want to "upgrade" to CoAP-EST,
but clearly there are some concerns about local key generation. I don't know
why exactly, but I suspect it has to with the validation (FIPS140) of the
libraries available on that platform: perhaps they are not validated to
create their own keys...(yet?)
But they can be field upgraded in an unattended fashion to use a standard
protocol, as long as they don't have to do new crypto tricks *today*.
(%)- In smaller/self-contained systems, the Registration Authority (RA) is
often co-located (part of, implemented by the same system) with the
Certificate Authority.
I actually don't know if the RA or CA generates the private key.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
