[pkix] Re: Name constraints in certificates

--===============3194257032671317440==
Content-Type: multipart/alternative; boundary="000000000000e162da0626f8762b"

--000000000000e162da0626f8762b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Phillip Hallam-Baker <phill@hallam=
baker.com>
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 LetsAuthenticat=
e
> 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.m=
esh
> 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 ha=
d
> 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 an=
d
> 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 o=
f
> 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.
>

--000000000000e162da0626f8762b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-size:small">Ooops,=C2=A0</div><div class=3D"gmail_default" style=3D"font-=
size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small=
">* Trust=C2=A0the LetsAuthenticate root</div><div class=3D"gmail_default" =
style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"f=
ont-size:small">Oh and, yes, I applied for the names before LetsEncrypt tho=
ugh 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 monopol=
y.</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><d=
iv class=3D"gmail_default" style=3D"font-size:small">On the ugliness=C2=A0o=
f direct names, it is quite possible this can be hidden behind hypertext li=
nks. I was just experimenting with the user &#39;device browser&#39; and th=
e user doesn&#39;t need to know the camera in their garage is garage-camera=
.<span style=3D"font-family:Calibri,sans-serif;font-size:14.6667px">mb5s-r4=
aj-3fbt-7nho-t26z-</span><span style=3D"font-family:Calibri,sans-serif;font=
-size:14.6667px">2e6y-wfh4.mesh</span></div><div class=3D"gmail_default" st=
yle=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"fon=
t-size:small">Where this goes pear shaped is if Alice stays at Bob&#39;s ho=
use and Bob wants to delegate control over stuff while she is there.</div><=
div class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=
=3D"gmail_default" style=3D"font-size:small"><br></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 15, 2024=
 at 12:50=E2=80=AFPM Phillip Hallam-Baker &lt;<a href=3D"mailto:phill@halla=
mbaker.com">[email protected]</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-size:s=
mall">I am looking at the problem of issuing certificates to IoT devices th=
at was raised in ALL-DISPATCH with a view to creating a proof of concept fo=
r the problem described as &#39;impossible&#39; :-)</div><div style=3D"font=
-size:small"><br></div><div style=3D"font-size:small">As it happens, I own =
the domains <a href=3D"http://letsauthenticate.com" target=3D"_blank">letsa=
uthenticate.com</a> and <a href=3D"http://letsauthenticate.org" target=3D"_=
blank">letsauthenticate.org</a> 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.</div><div style=3D"font-size:small"><br><=
/div><div style=3D"font-size:small">One of the nice properties of this sche=
me 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=C2=A0holding=C2=A0 the signature keys. So it tak=
es more than one party to defect for a bogus certificate to issue.</div><di=
v style=3D"font-size:small"><br></div><div style=3D"font-size:small"><br></=
div><div style=3D"font-size:small">The basic plan is that Alice registers t=
he UDF fingerprint of her Mesh root of trust=C2=A0<span style=3D"font-famil=
y:Calibri,sans-serif;font-size:11pt">mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4 wit=
h the=C2=A0</span>LetsAuthenticate threshold CA issues an Intermediate cert=
 to her with a name constraint allowing her to issue certs in the *.<span s=
tyle=3D"font-family:Calibri,sans-serif;font-size:11pt"><span class=3D"gmail=
_default" style=3D"font-size:small"></span>mb5s-r4aj-3fbt-7nho-t26z-2e6y-wf=
h4.mesh domain.</span></div><div style=3D"font-size:small"><br></div><div s=
tyle=3D"font-size:small">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.</div><div style=3D"font-s=
ize:small"><br></div><div style=3D"font-size:small"><br></div><div style=3D=
"font-size:small">The resulting certificates would be recognized by any Web=
 browser that had the specific configuration to recognize them:</div><div s=
tyle=3D"font-size:small"><br></div><div style=3D"font-size:small">* Refer r=
equests for .mesh to a resolver that handles them</div><div style=3D"font-s=
ize:small">* Trust=C2=A0the LetsEncrypt root</div><div style=3D"font-size:s=
mall">* Perform the appropriate pathmath to check the end entity cert.</div=
><div style=3D"font-size:small"><br></div><div style=3D"font-size:small">No=
w as it happens, I have my own browser, Phill&#39;s Hypothetical Browser an=
d that allows me to meet what I consider to be the core requirement that so=
meone should be able to buy an IoT device from wherever, plonk it onto thei=
r network and configure it through a Mesh enabled browser without any perso=
nalization to their personal account. (PHB has the LetsAuthenticate Root in=
stalled, it does not need an Alice root).</div><div style=3D"font-size:smal=
l"><br></div><div style=3D"font-size:small">Of course, I am aware the use o=
f Direct names is ugly but I have a solution for that as well, as most of y=
ou know. And building a friendly name registration service like callsign mi=
ght be the way to fund this infrastructure if it becomes widely=C2=A0used.<=
/div><div style=3D"font-size:small"><br></div><div style=3D"font-size:small=
"><br></div><div style=3D"font-size:small">In the short term, I am somewhat=
 concerned about the risk of unexpected effects in the legacy WebPKI. I wil=
l mark the name constraints critical of course. But would there be conseque=
nces if the user installs the LetsAuthenticate root?</div><div style=3D"fon=
t-size:small"><br></div><div style=3D"font-size:small">I would ideally want=
 to put name constraints in the root cert but that isn&#39;t a thing of cou=
rse because root certs aren&#39;t really certs.</div></div>
</blockquote></div></div>

--000000000000e162da0626f8762b--


--===============3194257032671317440==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK

--===============3194257032671317440==--