[pkix] Re: Name constraints in certificates

--===============3396478628475810497==
Content-Type: multipart/alternative; boundary="0000000000001528860626f9ff42"

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

My plan would be to constrain the intermediates to issue certificates with
subject alt names in the corresponding callsign domain and nothing else, no
IP address certs.

I can't see the value of the callsign CA issuing SRVName certs as the
concept is that it is a purely deterministic system where the quorum of
threshold-signers create intermediate certs according to the entries in the
callsign binding that delegate control over that name to a party determined
by the callsign holder.

I guess you are warning me about 3280

4.2.1.11 <https://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.11>
Name Constraints

...

Restrictions apply only when the specified name form is present.

If no name of the type is in the certificate, the certificate is

acceptable


Ugh..

Not much better in 5280:

4.2.1.10 <https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10>.
Name Constraints


I have been looking and cannot see normative language describing the
interpretation of permitted subtrees anywhere. What
I would have expected is that if the permitted subtrees is non-empty,
certificates can only be issued if they are in permitted trees and not in
excluded.

It seems that what we have to do instead is specify e.g. alice123.mesh in
permitted trees and then exclude every other name type explicitly.


On Fri, Nov 15, 2024 at 3:33=E2=80=AFPM Corey Bonnell <Corey.Bonnell@digice=
rt.com>
wrote:

> Hi Phill,
>
> At the very least, you will want iPAddress constraints included as well,
> otherwise the local CA could issue end-entity certificates for any
> arbitrary IP address that would be trusted by relying parties. You may al=
so
> want constraints on other name forms (e.g., SRVName otherNames), dependin=
g
> on the support for such name forms in client software you are targeting.
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Phillip Hallam-Baker <[email protected]>
> *Sent:* Friday, November 15, 2024 2:21 PM
> *To:* [email protected]
> *Subject:* [pkix] Re: Name constraints in certificates
>
>
>
> 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 want=
s
> to delegate control over stuff while she is there.
>
>
>
>
>
>
>
> On Fri, Nov 15, 2024 at 12:50=E2=80=AFPM Phillip Hallam-Baker <
> [email protected]> 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.
>
>

--0000000000001528860626f9ff42
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">My plan would be to constrain the intermediates to issue cert=
ificates with subject alt names in the corresponding callsign domain and no=
thing else, no IP address certs.</div><div class=3D"gmail_default" style=3D=
"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size=
:small">I can&#39;t see the value of the callsign CA issuing SRVName certs =
as the concept is that it is a purely deterministic system where the quorum=
 of threshold-signers create intermediate certs according to the entries in=
 the callsign binding that delegate control over that name to a party deter=
mined by the callsign holder.</div><div class=3D"gmail_default" style=3D"fo=
nt-size:small"><br></div><div class=3D"gmail_default" style=3D"font-size:sm=
all">I guess you are warning me about 3280</div><div class=3D"gmail_default=
" style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D=
"font-size:small"><pre class=3D"gmail-newpage" style=3D"font-size:13.3333px=
;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span=
 class=3D"gmail-h5" style=3D"display:inline;font-size:1em;font-weight:bold"=
><a class=3D"gmail-selflink" id=3D"gmail-section-4.2.1.11" href=3D"https://=
www.rfc-editor.org/rfc/rfc3280#section-4.2.1.11" style=3D"color:black;text-=
decoration-line:none">4.2.1.11</a>  Name Constraints</span></pre><pre class=
=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;margin-botto=
m:0px;break-before:page;color:rgb(0,0,0)"><span class=3D"gmail-h5" style=3D=
"display:inline;font-size:1em;font-weight:bold">...</span></pre></div><div =
class=3D"gmail_default" style=3D"font-size:small"><pre class=3D"gmail-newpa=
ge" style=3D"font-size:13.3333px;margin-top:0px;margin-bottom:0px;break-bef=
ore:page;color:rgb(0,0,0)">Restrictions apply only when the specified name =
form is present.</pre><pre class=3D"gmail-newpage" style=3D"font-size:13.33=
33px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)">I=
f no name of the type is in the certificate, the certificate is </pre><pre =
class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;margin-=
bottom:0px;break-before:page;color:rgb(0,0,0)">acceptable</pre></div><div c=
lass=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gm=
ail_default" style=3D"font-size:small">Ugh..</div><div class=3D"gmail_defau=
lt" style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=
=3D"font-size:small">Not much better in 5280:</div><div class=3D"gmail_defa=
ult" style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=
=3D"font-size:small"><pre class=3D"gmail-newpage" style=3D"font-size:13.333=
3px;margin-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><s=
pan class=3D"gmail-h5" style=3D"display:inline;font-size:1em;font-weight:bo=
ld"><a class=3D"gmail-selflink" id=3D"gmail-section-4.2.1.10" href=3D"https=
://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10" style=3D"color:black;te=
xt-decoration-line:none">4.2.1.10</a>.  Name Constraints</span></pre><pre c=
lass=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;margin-b=
ottom:0px;break-before:page;color:rgb(0,0,0)"><span class=3D"gmail-h5" styl=
e=3D"display:inline;font-size:1em;font-weight:bold"><br></span></pre></div>=
<div class=3D"gmail_default" style=3D"font-size:small">I have been looking=
=C2=A0and cannot see normative language describing=C2=A0the interpretation =
of permitted subtrees anywhere. What=C2=A0</div><div class=3D"gmail_default=
" style=3D"font-size:small">I would have expected is that if the permitted =
subtrees is non-empty, certificates can only be issued if they are in permi=
tted=C2=A0trees and not in excluded.</div><div class=3D"gmail_default" styl=
e=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-=
size:small">It seems that what we have to do instead is specify e.g. alice1=
23.mesh=C2=A0in permitted trees and then exclude every other name type expl=
icitly.=C2=A0</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"gma=
il_attr">On Fri, Nov 15, 2024 at 3:33=E2=80=AFPM Corey Bonnell &lt;<a href=
=3D"mailto:[email protected]">[email protected]</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=
=3D"msg1772699075817507737"><div lang=3D"EN-US" style=3D"overflow-wrap: bre=
ak-word;"><div class=3D"m_1772699075817507737WordSection1"><p class=3D"MsoN=
ormal"><span style=3D"font-size:11pt">Hi Phill,<u></u><u></u></span></p><p =
class=3D"MsoNormal"><span style=3D"font-size:11pt">At the very least, you w=
ill want iPAddress constraints included as well, otherwise the local CA cou=
ld issue end-entity certificates for any arbitrary IP address that would be=
 trusted by relying parties. You may also want constraints on other name fo=
rms (e.g., SRVName otherNames), depending on the support for such name form=
s in client software you are targeting.<u></u><u></u></span></p><p class=3D=
"MsoNormal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u></span></p><=
p class=3D"MsoNormal"><span style=3D"font-size:11pt">Thanks,<u></u><u></u><=
/span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt">Corey<u></u=
><u></u></span></p><p class=3D"MsoNormal"><span style=3D"font-size:11pt"><u=
></u>=C2=A0<u></u></span></p><div style=3D"border-right:none;border-bottom:=
none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in=
 0in"><p class=3D"MsoNormal"><b><span style=3D"font-size:11pt;font-family:C=
alibri,sans-serif">From:</span></b><span style=3D"font-size:11pt;font-famil=
y:Calibri,sans-serif"> Phillip Hallam-Baker &lt;<a href=3D"mailto:phill@hal=
lambaker.com" target=3D"_blank">[email protected]</a>&gt; <br><b>Sent:<=
/b> Friday, November 15, 2024 2:21 PM<br><b>To:</b> <a href=3D"mailto:pkix@=
ietf.org" target=3D"_blank">[email protected]</a><br><b>Subject:</b> [pkix] Re:=
 Name constraints in certificates<u></u><u></u></span></p></div><p class=3D=
"MsoNormal"><u></u>=C2=A0<u></u></p><div><div><div><p class=3D"MsoNormal">O=
oops,=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=
=A0<u></u></p></div><div><p class=3D"MsoNormal">* Trust=C2=A0the LetsAuthen=
ticate root<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=
=A0<u></u></p></div><div><p class=3D"MsoNormal">Oh and, yes, I applied for =
the names before LetsEncrypt though to apply for a trademark. My thought be=
ing that at some point, we might decide we needed to avoid the provision of=
 WebPKI certs becoming a monopoly.<u></u><u></u></p></div><div><p class=3D"=
MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">On the=
 ugliness=C2=A0of direct names, it is quite possible this can be hidden beh=
ind hypertext links. I was just experimenting with the user &#39;device bro=
wser&#39; and the user doesn&#39;t need to know the camera in their garage =
is garage-camera.<span style=3D"font-size:11pt;font-family:Calibri,sans-ser=
if">mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4.mesh</span><u></u><u></u></p></div><=
div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"M=
soNormal">Where this goes pear shaped is if Alice stays at Bob&#39;s house =
and Bob wants to delegate control over stuff while she is there.<u></u><u><=
/u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div=
><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div></div><p class=3D"Mso=
Normal"><u></u>=C2=A0<u></u></p><div><div><p class=3D"MsoNormal">On Fri, No=
v 15, 2024 at 12:50<span style=3D"font-family:Arial,sans-serif">=E2=80=AF</=
span>PM Phillip Hallam-Baker &lt;<a href=3D"mailto:[email protected]" t=
arget=3D"_blank">[email protected]</a>&gt; wrote:<u></u><u></u></p></di=
v><blockquote style=3D"border-top:none;border-right:none;border-bottom:none=
;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left=
:4.8pt;margin-right:0in"><div><div><p class=3D"MsoNormal">I am looking at t=
he problem of issuing certificates to IoT devices that was raised in ALL-DI=
SPATCH with a view to creating a proof of concept for the problem described=
 as &#39;impossible&#39; :-)<u></u><u></u></p></div><div><p class=3D"MsoNor=
mal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">As it happen=
s, I own the domains <a href=3D"http://letsauthenticate.com" target=3D"_bla=
nk">letsauthenticate.com</a> and <a href=3D"http://letsauthenticate.org" ta=
rget=3D"_blank">letsauthenticate.org</a> and these could be used to create =
a sister service to letsencrypt but focused on devices and issuing certific=
ates that are bound to non-IANA DNS names.<u></u><u></u></p></div><div><p c=
lass=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal=
">One of the nice properties of this scheme is that I can construct a CA wh=
ose operation is entirely constrained by the operation of the naming infras=
tructure and employs separation of duties between a set of entities=C2=A0ho=
lding=C2=A0 the signature keys. So it takes more than one party to defect f=
or a bogus certificate to issue.<u></u><u></u></p></div><div><p class=3D"Ms=
oNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=
=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">The basic plan is that A=
lice registers the UDF fingerprint of her Mesh root of trust=C2=A0<span sty=
le=3D"font-size:11pt;font-family:Calibri,sans-serif">mb5s-r4aj-3fbt-7nho-t2=
6z-2e6y-wfh4 with the=C2=A0</span>LetsAuthenticate threshold CA issues an I=
ntermediate cert to her with a name constraint allowing her to issue certs =
in the *.<span style=3D"font-size:11pt;font-family:Calibri,sans-serif">mb5s=
-r4aj-3fbt-7nho-t26z-2e6y-wfh4.mesh domain.</span><u></u><u></u></p></div><=
div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"M=
soNormal">Alice can now issue certificates through her local CA which could=
 again make use of threshold to provide separation of duties between her lo=
cal device and an offsite service.<u></u><u></u></p></div><div><p class=3D"=
MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u=
>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">The resulting certifica=
tes would be recognized by any Web browser that had the specific configurat=
ion to recognize them:<u></u><u></u></p></div><div><p class=3D"MsoNormal"><=
u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">* Refer requests f=
or .mesh to a resolver that handles them<u></u><u></u></p></div><div><p cla=
ss=3D"MsoNormal">* Trust=C2=A0the LetsEncrypt root<u></u><u></u></p></div><=
div><p class=3D"MsoNormal">* Perform the appropriate pathmath to check the =
end entity cert.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=
=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">Now as it happens, I hav=
e my own browser, Phill&#39;s Hypothetical Browser and that allows me to me=
et what I consider to be the core requirement that someone should be able t=
o buy an IoT device from wherever, plonk it onto their network and configur=
e it through a Mesh enabled browser without any personalization to their pe=
rsonal account. (PHB has the LetsAuthenticate Root installed, it does not n=
eed an Alice root).<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u><=
/u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">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 c=
allsign might be the way to fund this infrastructure if it becomes widely=
=C2=A0used.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=
=A0<u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></d=
iv><div><p class=3D"MsoNormal">In the short term, I am somewhat concerned a=
bout the risk of unexpected effects in the legacy WebPKI. I will mark the n=
ame constraints critical of course. But would there be consequences if the =
user installs the LetsAuthenticate root?<u></u><u></u></p></div><div><p cla=
ss=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">=
I would ideally want to put name constraints in the root cert but that isn&=
#39;t a thing of course because root certs aren&#39;t really certs.<u></u><=
u></u></p></div></div></blockquote></div></div></div></div></div></blockquo=
te></div></div>

--0000000000001528860626f9ff42--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK

--===============3396478628475810497==--