A proposal of https certificate assignment system for luci

[Michael Richardson]

abnoeh <abnoeh at mail.com> wrote:
    > Openwrt as project get a CA certificate with name constrained to only
    > able to sign subdomains of [luci.openwrt.org]. this makes we
    > Technically Constrained Subordinate CA, (from let's encrypt or
    > digicert), let's call it the Openwrt CA here (CA ) this makes we don't
    > create too much load to normal CA like let's encrypt, and as we have
    > complete control of this zone we can give subdomains as we want like,
    > and don't need full audit like fully pledged CA and handled like a
    > wildcard cert for them, but the CA system can be hosted by us and
    > request won't offloaded to upper CA's server. (except OCSP request, but
    > it can be cashed)

While this is a technically correct solution, it may be politically impossible.
The CABForum insists that any Subordinate CA that we might get has to be
constrained by the CABForum rules.
If we don't comply, then Mozilla/Google/Apple will force whatever root CA
that signs us to revoke the subCA.  (I think that this really really sucks)

That's essentially why Enterprise subordinate CAs have gone away.

The CAs now offer to host Enterprise CAs in their cloud, where they can do
all the right things to remain compliant.  Most enterprises find that
annoying and expensive, and so they go the way of generating their own
private CA.

If we can live with the constraints, and can find a CA willing to delegate a
subordinate CA to us, then let's try.

    > {everything below will be done on https or otherwise encrypted channel}
    > 1. on first boot, router want to get it's luci certificate send its ssh
    > host key to Openwrt CA reserve subdomain base32(hash of public
    > key).luci.openwrt.org (like onion v3 addressed does)
    > 2. Openwrt CA sends nonce to our router
    > 3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
    > and send back to openwrt CA send this signed message with CSR
    > 4. Openwrt CA verify other end controls host key match
    > with hash and confirmed the CSR, sign the certificate with (key from
    > CSR/SAN with domain we derived from host key) and sent back to router
    > 5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt
    > lan to https version of signed subdomain

This an interesting process, leveraging the SSH key as part of the unique part.
I prefer to use ULA, and to find a way to store ULA in eeprom.
However, I think you are assuming a RA/DHCP-based WAN connection.
For PPPoE (which is still a thing in a lot of places, including developing
world, where last mile is often wifi), this won't work that well.

    > now user only have to check :
    > 1. page has valid certificate
    > 2. the subdomain is match with device's ssh host key
    > and this verify  it's the device we wanted.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20201005/6682b30f/attachment.sig>