[pkix] Re: Name constraints in certificates

[Phillip Hallam-Baker <[e-mail]>]

Ooops,

* Trust the LetsAuthenticate root

Oh and, yes, I applied for the names before LetsEncrypt though to apply for
a trademark. My thought being that at some point, we might decide we needed
to avoid the provision of WebPKI certs becoming a monopoly.

On the ugliness of direct names, it is quite possible this can be hidden
behind hypertext links. I was just experimenting with the user 'device
browser' and the user doesn't need to know the camera in their garage is
garage-camera.mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4.mesh

Where this goes pear shaped is if Alice stays at Bob's house and Bob wants
to delegate control over stuff while she is there.



On Fri, Nov 15, 2024 at 12:50 PM Phillip Hallam-Baker <[e-mail]>
wrote:

> I am looking at the problem of issuing certificates to IoT devices that
> was raised in ALL-DISPATCH with a view to creating a proof of concept for
> the problem described as 'impossible' :-)
>
> As it happens, I own the domains letsauthenticate.com and
> letsauthenticate.org and these could be used to create a sister service
> to letsencrypt but focused on devices and issuing certificates that are
> bound to non-IANA DNS names.
>
> One of the nice properties of this scheme is that I can construct a CA
> whose operation is entirely constrained by the operation of the naming
> infrastructure and employs separation of duties between a set of
> entities holding  the signature keys. So it takes more than one party to
> defect for a bogus certificate to issue.
>
>
> The basic plan is that Alice registers the UDF fingerprint of her Mesh
> root of trust mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4 with the LetsAuthenticate
> threshold CA issues an Intermediate cert to her with a name constraint
> allowing her to issue certs in the *.mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4.mesh
> domain.
>
> Alice can now issue certificates through her local CA which could again
> make use of threshold to provide separation of duties between her local
> device and an offsite service.
>
>
> The resulting certificates would be recognized by any Web browser that had
> the specific configuration to recognize them:
>
> * Refer requests for .mesh to a resolver that handles them
> * Trust the LetsEncrypt root
> * Perform the appropriate pathmath to check the end entity cert.
>
> Now as it happens, I have my own browser, Phill's Hypothetical Browser and
> that allows me to meet what I consider to be the core requirement that
> someone should be able to buy an IoT device from wherever, plonk it onto
> their network and configure it through a Mesh enabled browser without any
> personalization to their personal account. (PHB has the LetsAuthenticate
> Root installed, it does not need an Alice root).
>
> Of course, I am aware the use of Direct names is ugly but I have a
> solution for that as well, as most of you know. And building a friendly
> name registration service like callsign might be the way to fund this
> infrastructure if it becomes widely used.
>
>
> In the short term, I am somewhat concerned about the risk of unexpected
> effects in the legacy WebPKI. I will mark the name constraints critical of
> course. But would there be consequences if the user installs the
> LetsAuthenticate root?
>
> I would ideally want to put name constraints in the root cert but that
> isn't a thing of course because root certs aren't really certs.
>