Re: Security Working Group meeting - this Wednesday February 19 - summary results

[Michael Richardson <mcr@sandelman.ca>]

[-- Attachment #1: Type: text/plain, Size: 1707 bytes --]


James Feist <james.feist@linux.intel.com> wrote:
    > I think the original motivation of 10 years was something above the average
    > support cycle of a server, so on first boot the user has something they can
    > use to login to the server with.

That's not a crazy consideration to me.

    > That being said, if the browser wont let you
    > in, that is obviously more important. 30 days seems a bit too strict
    > considering shipping / unpacking times make it likely you'll have an expired
    > certificate upon arrival. But if we can't come to an agreement, we can always
    > make this configurable.

1) it would be good to clarify what browsers are really going to do.

2) it won't apply to CURL, etc. which might be used to onboard a system
   automatically.

3) you can't make it configurable, because you can't configure it if you
   can't connect :-)

825 days (27 months, so 2yr plus some wiggle room) is definitely what they
are going to for built-in trust anchors.  I'm not sure if this will apply
to trust anchors that are loaded into browsers by end users, or if that
configuration will somehow be attached to the trust anchor.

So, if 825 days is a good default, I'd make it 820 days, and after 410 days,
I'd have the self-signed certificate resigned, but not generate a new private
key.   This allows for mgmt stations to pin the public key of the BMC,
ignoring the actual certificate contents.

I will try to send a patch to do this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]