[openssl-users] Another problem with openssl x509 -req -- default_enddate

[Robert Moskowitz]

On 08/30/2017 09:22 PM, Michael Richardson wrote:
> Viktor Dukhovni <openssl-users at dukhovni.org> 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