On 08/30/2017 09:22 PM, Michael Richardson wrote:
Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote:
> So indeed, you'd not be the first to consider a special-purpose
> concise format. It is somewhat surprising that the applications
> you're considering use X.509 certificates at all, rather than just
> raw public keys. With expiration times in the year "9999", the
> extra bloat of certificates is perhaps just useless baggage.
We are leveraging the political unity behind 802.1AR (which defines the
IDevID). As a profile it's pretty thin, relying extensively (but
appropriately) on IETF documents, yet still leaving a bunch of stuff rather
under-specified.
By intent.
While devices possessing IDevIDs don't need all the cert chain stuff,
the network infrastructure validating them may need it. Given supply chain
complexity, it could well be in the IDevID that linking back to the
manufacturer requires a chain of certificates. (My KitchenAid dishwasher is
made and serviced by Whirlpool, but was sold to me by Sears. I'd expect
Sears' certificate to be in the electronic invoice)
Actually there was extensive discussion that this would be LDevIDs. The
manufacturer is KitchenAId. Their IDevID. So that Whirlpool can
service it, a Whirlpool LDevID. We could not come to any consistent
scenario on Sears as the Merchant. No real difference than Target
selling a TracPhone. What interaction do they have after the sale?
Or there is NO KitchenAid Identity in the machine. They were just a job
shop for Whirlpool so only a Whirlpool IDevID...
You missed out on all the fun discussions, Michael. You just get to
pick up the pieces!
The real drivers, at the time was Cisco and Aruba for their phones...
> Admittedly, I don't know how the security model in question relates
> to the real-world constraints of the supply chain, who gets to sign
> certificates for devices allowed to participate, and whether a
> certificateless public key database might have been a realistic
> option.
No, it's just not.
In the 6tisch (constrained) version of BRSKI, which is at:
https://bitbucket.org/6tisch/draft-richardson-6tisch-dtsecurity-secure-join/src/b84347549d469806067cf60b323444f97a98ee83/dtsecurity-zerotouch-join-00.txt?at=master&fileviewer=file-view-default
until the rename of the document is approved. Section 2.2 explains that the
constrained device will have/need only the raw public key of the manufacturer, and
will treat the IDevID as a blob. The private key should be stored in
whatever form is most convenient for computation, like the Apple boot loader
does. Still, some people will have TPMs with complicated interfaces.
Lots of groups taking the basics and putting them together in a way that
SHOULD work for them...
Bob
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
