[pkix] Name constraints in certificates

--===============0787969890412885935==
Content-Type: multipart/alternative; boundary="000000000000c536c50626f734e7"

--000000000000c536c50626f734e7
Content-Type: text/plain; charset="UTF-8"

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.

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

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">I a=
m looking at the problem of issuing certificates to IoT devices that was ra=
ised in ALL-DISPATCH with a view to creating a proof of concept for the pro=
blem described as &#39;impossible&#39; :-)</div><div class=3D"gmail_default=
" style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D=
"font-size:small">As it happens, I own the domains <a href=3D"http://letsau=
thenticate.com">letsauthenticate.com</a> and <a href=3D"http://letsauthenti=
cate.org">letsauthenticate.org</a> and these could be used to create a sist=
er service to letsencrypt but focused on devices and issuing certificates t=
hat are bound to non-IANA DNS names.</div><div class=3D"gmail_default" styl=
e=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-=
size:small">One of the nice properties of this scheme is that I can constru=
ct a CA whose operation is entirely constrained by the operation of the nam=
ing infrastructure and employs separation of duties between a set of entiti=
es=C2=A0holding=C2=A0 the signature keys. So it takes more than one party t=
o defect for a bogus certificate to issue.</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 class=3D"gmail_default" style=3D"font-size=
:small">The basic plan is that Alice registers the UDF fingerprint of her M=
esh root of trust=C2=A0<span style=3D"font-family:Calibri,sans-serif;font-s=
ize:11pt">mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4 with the=C2=A0</span>LetsAuthe=
nticate threshold CA issues an Intermediate cert to her with a name constra=
int allowing her to issue certs in the *.<span style=3D"font-family:Calibri=
,sans-serif;font-size:11pt">mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4.mesh domain.=
</span></div><div class=3D"gmail_default" style=3D"font-size:small"><br></d=
iv><div class=3D"gmail_default" style=3D"font-size:small">Alice can now iss=
ue certificates through her local CA which could again make use of threshol=
d to provide separation of duties between her local device and an offsite s=
ervice.</div><div class=3D"gmail_default" style=3D"font-size:small"><br></d=
iv><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div cl=
ass=3D"gmail_default" 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 class=3D"gmail_default" style=3D"font-size:sma=
ll"><br></div><div class=3D"gmail_default" style=3D"font-size:small">* Refe=
r requests for .mesh to a resolver that handles them</div><div class=3D"gma=
il_default" style=3D"font-size:small">* Trust=C2=A0the LetsEncrypt root</di=
v><div class=3D"gmail_default" style=3D"font-size:small">* Perform the appr=
opriate pathmath to check the end entity cert.</div><div class=3D"gmail_def=
ault" style=3D"font-size:small"><br></div><div class=3D"gmail_default" styl=
e=3D"font-size:small">Now as it happens, I have my own browser, Phill&#39;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 wher=
ever, plonk it onto their network and configure it through a Mesh enabled b=
rowser without any personalization to their personal account. (PHB has the =
LetsAuthenticate Root installed, it does not need an Alice root).</div><div=
 class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"=
gmail_default" style=3D"font-size:small">Of course, I am aware the use of D=
irect 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=C2=A0used.</di=
v><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div cla=
ss=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gmai=
l_default" style=3D"font-size:small">In the short term, I am somewhat conce=
rned about the risk of unexpected effects in the legacy WebPKI. I will mark=
 the name constraints critical of course. But would there be consequences i=
f the user installs the LetsAuthenticate root?</div><div class=3D"gmail_def=
ault" style=3D"font-size:small"><br></div><div class=3D"gmail_default" styl=
e=3D"font-size:small">I would ideally want to put name constraints in the r=
oot cert but that isn&#39;t a thing of course because root certs aren&#39;t=
 really certs.</div></div>

--000000000000c536c50626f734e7--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK

--===============0787969890412885935==--