A proposal of https certificate assignment system for luci

[abnoeh]

20. 10. 6. 오전 1:29에 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)


actually making our CA to Technically Constrained as CA/B 7.1.5 will
make we exempted from most of those audit requirements, just section 8.7
which is just we and our parent CA should check we are adhere to our own
CPS. and most root program take same approach, you should be name locked
or be public and audited.

form 8.1 Frequency or circumstances of assessmentCertificates that are
capable of being used to issue new certificates MUST either be
Technically Constrained in line with section 7.1.5 and audited in line
with section 8.7 only


> 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.

using ssh key as unique part was to solve problem of 'Are you sure you
are looking at right page even at worst state (like dns hijack or remote
management over the internet) so I wanted to make domain something can
be cryptically connected to the device we connect, and ssh key was first
and only key we have.

maybe enforce cert's pubkey == ssh pubkey == domain kind of way be
better, but browsers don't support ed25519, or CA/B allow to make one,
so it need ssh-keescan to see key if device check ed25519 key by default.

> 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.

at the end entire reason we need certificate is we having a webserver,
and all luci will do at the backend is running  uci conmmand, can we run
luci on client side, and send uci command to ssh, wrap it all under the
name of "easy-installer"?

if we don't have webserver we don't need a certificate. or uhttpd, in fact.

> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel