[pkix] Re: Name constraints in certificates
Phillip Hallam-Baker <[email protected]> Tue, 19 Nov 2024 11:14:07 -0500
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <CAMm+Lwh_ZSwNuuaz6DROekEwhNjXPFhDifHMDqaknJ1LiumVuA@mail.gmail.com> |
--===============2627598877212143887==
Content-Type: multipart/alternative; boundary="0000000000003f72650627465367"
--0000000000003f72650627465367
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I am not reading this the way you appear to be:
6.1.3 <https://www.rfc-editor.org/rfc/rfc5280.html#section-6.1.3>.
Basic Certificate Processing
(b) If certificate i is self-issued and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is within one of the
permitted_subtrees for X.500 distinguished names, and verify
that each of the alternative names in the subjectAltName
extension (critical or non-critical) is within one of the
permitted_subtrees for that name type.
Now admittedly, the way I would write it is 'if check fails REJECT'. But to
me a subjectAltName that isn't in any permitted subtree fails this check.
In my case, the first certificate in the chain (i.e. the intermediate as
the root is not a certificate) will have a name constraint which only
permits the names *.mesh for domain name and SRV name (I definitely want to
allow services). So at that point all other names will be prohibited.
The cross certificate for alice's domain alice1234.mesh then has a
permitted tree for *.alice1234.mesh and issue is constrained to the
intersection of the constraints from both (and same for SRVNAME)
I note 6.1.4. (g).1:
If permittedSubtrees does not include a
particular name type, the permitted_subtrees state
variable is unchanged for that name type.
Which is likely a real problem for WebPKI certs because the spec suggest
that only the first cert in the chain has the property 'must be within a
permitted tree'. And that doesn't work if that cert is delegating
issue capability to an affiliate.
Of course, that is only the spec. What code in the field does....
One way to save the appearances would be to put in excluded subtrees for
all the name types currently in use and define a new OID to act as a
wildcard and assume that any party that wants to make use of a new name
type is going to do the right thing. That would allow an 'exclude all other
names' restriction to be added at the mid point in a trust chain.
After all, if someone is writing an app that does use some different name
form that is outside the WebPKI scope (i.e. not a dns name, ip address or
SRV name) and decide to trust roots they find in the WebPKI root store,
well, that is on their head.
If we needed to add the ability to issue for a new name type to this
contraption, the holders of the offline root shares would have to assemble
and issue a new intermediate with a constraint to allow that type of cert.
Is it worth proposing an 'allOtherNames' name type to LAMPS?
On Fri, Nov 15, 2024 at 5:35=E2=80=AFPM Corey Bonnell <Corey.Bonnell@digice=
rt.com>
wrote:
> > I guess you are warning me about 3280
>
>
>
> Yes.
>
>
>
> > 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.
>
>
>
> Sections 6.1.3 and 6.1.4 of RFC 5280 goes into detail how
> permittedSubtrees and excludedSubtrees are processed. In particular, see
> 6.1.3 (b), 6.1.3 (c) and 6.1.4 (i). Annex G.3 of X.509 (2005/08) also has
> some nice examples.
>
>
>
> What you say about non-empty permittedSubtrees is correct, but that
> restriction only exists for the specific name form under consideration.
>
>
>
> > 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.
>
>
>
> Yes, but even then, the list will be incomplete. Someone could create an
> arbitrary otherName type with their own OID and issue certs with such an
> otherName in the SAN. Also, it is not possible to encode a blanket
> prohibition on SRVName [1]. Whether these limitations manifest in a
> concrete issue for client software is dependent on whether they support
> such name forms (or handle unknown name forms in a dangerous manner).
>
>
>
> [1]
> https://mailarchive.ietf.org/arch/msg/pkix/_B_-huGzs217NQqoR4Kk5_lqOh0/
>
>
>
> Thanks,
>
> Corey
>
>
>
> *From:* Phillip Hallam-Baker <[email protected]>
> *Sent:* Friday, November 15, 2024 4:10 PM
> *To:* Corey Bonnell <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [pkix] Re: Name constraints in certificates
>
>
>
> My plan would be to constrain the intermediates to issue certificates wit=
h
> 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 t=
he
> callsign binding that delegate control over that name to a party determin=
ed
> 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>* Na=
me 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>*. N=
ame 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@digi=
cert.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.
>
>
--0000000000003f72650627465367
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:small">I am not r=
eading this the way you appear to be:</div><div class=3D"gmail_default" sty=
le=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;marg=
in-top:0px;margin-bottom:0px;break-before:page;color:rgb(0,0,0)"><span clas=
s=3D"gmail-h4" style=3D"display:inline;font-size:1em;font-weight:bold"><a c=
lass=3D"gmail-selflink" id=3D"gmail-section-6.1.3" href=3D"https://www.rfc-=
editor.org/rfc/rfc5280.html#section-6.1.3" style=3D"color:black;text-decora=
tion-line:none">6.1.3</a>. Basic Certificate Processing</span></pre></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;brea=
k-before:page;color:rgb(0,0,0)"> (b) If certificate i is self-issued =
and it is not the final
certificate in the path, skip this step for certificate i.
Otherwise, verify that the subject name is within one of the
permitted_subtrees for X.500 distinguished names, and verify
that each of the alternative names in the subjectAltName
extension (critical or non-critical) is within one of the
permitted_subtrees for that name type.</pre></div><div class=3D"=
gmail_default" style=3D"font-size:small"><br></div><div class=3D"gmail_defa=
ult" style=3D"font-size:small">Now admittedly, the way I would write it is =
'if check fails REJECT'. But to me a=C2=A0<span style=3D"color:rgb(=
0,0,0);font-size:13.3333px">subjectAltName</span>=C2=A0that isn't in an=
y permitted subtree fails this check.</div><div class=3D"gmail_default" sty=
le=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font=
-size:small">In my case, the first certificate in the chain (i.e. the inter=
mediate as the root is not a certificate) will have a name constraint which=
only permits the names *.mesh for domain name and SRV name (I definitely w=
ant to allow services). So at that point all other names will be prohibited=
.</div><div class=3D"gmail_default" style=3D"font-size:small"><br></div><di=
v class=3D"gmail_default" style=3D"font-size:small">The cross certificate f=
or alice's domain alice1234.mesh then has a permitted tree for *.alice1=
234.mesh=C2=A0and issue is constrained to the intersection of the constrain=
ts from both (and same for SRVNAME)</div><div class=3D"gmail_default" style=
=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-s=
ize:small"><br></div><div class=3D"gmail_default" style=3D"font-size:small"=
>I note 6.1.4. (g).1:</div><div class=3D"gmail_default" style=3D"font-size:=
small"><br></div><div class=3D"gmail_default" style=3D"font-size:small"><pr=
e class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;margi=
n-bottom:0px;break-before:page;color:rgb(0,0,0)"> If permittedSubtrees does=
not include a
particular name type, the permitted_subtrees state
variable is unchanged for that name type. </pre></div><div cl=
ass=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"gma=
il_default" style=3D"font-size:small">Which is likely a real problem for We=
bPKI certs because the spec suggest that only the first cert in the chain h=
as the property 'must be within a permitted tree'. And that doesn&#=
39;t work if that cert is delegating issue=C2=A0capability to an affiliate.=
</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, that is only =
the spec. What code in the field does....</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">One way to save the appearances would be to put in excluded subtrees=
for all the name types currently in use and define a new OID to act as a w=
ildcard and assume that any party that wants to make use of a new name type=
is going to do the right thing. That would allow an 'exclude all other=
names' restriction to be added at the mid point in a trust chain.</div=
><div class=3D"gmail_default" style=3D"font-size:small"><br></div><div clas=
s=3D"gmail_default" style=3D"font-size:small">After all, if someone is writ=
ing an app that does use some different name form that is outside the WebPK=
I scope (i.e. not a dns name, ip address or SRV name) and decide to trust r=
oots they find in the WebPKI root store, well, that is on their head.</div>=
<div class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=
=3D"gmail_default" style=3D"font-size:small">If we needed to add the abilit=
y to issue for a new name type to this contraption, the holders of the offl=
ine root shares would have to assemble and issue a new intermediate with a =
constraint to allow that type of cert.</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"><br></div><div class=3D"gmail_default" style=3D"font-size:sma=
ll">Is it worth proposing an 'allOtherNames' name type to LAMPS?</d=
iv></div></div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D=
"ltr" class=3D"gmail_attr">On Fri, Nov 15, 2024 at 5:35=E2=80=AFPM Corey Bo=
nnell <<a href=3D"mailto:[email protected]">Corey.Bonnell@digic=
ert.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div class=3D"msg2041460895052691502">
<div lang=3D"EN-US" style=3D"overflow-wrap: break-word;"><div class=3D"m_20=
41460895052691502WordSection1"><p class=3D"MsoNormal"><span style=3D"font-s=
ize:11pt">> </span>I guess you are warning me about 3280<u></u><u></u></=
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">Yes.<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-si=
ze:11pt">> </span>I have been looking=C2=A0and cannot see normative lang=
uage describing=C2=A0the interpretation of permitted subtrees anywhere. Wha=
t=C2=A0I would have expected is that if the permitted subtrees is non-empty=
, certificates can only be issued if they are in permitted=C2=A0trees and n=
ot in excluded.<u></u><u></u></p><p class=3D"MsoNormal"><span style=3D"font=
-size:11pt"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoNormal"><span sty=
le=3D"font-size:11pt">Sections 6.1.3 and 6.1.4 of RFC 5280 goes into detail=
how permittedSubtrees and excludedSubtrees are processed. In particular, s=
ee 6.1.3 (b), 6.1.3 (c) and 6.1.4 (i). Annex G.3 of X.509 (2005/08) also ha=
s some nice examples.<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"MsoNorm=
al"><span style=3D"font-size:11pt">What you say about non-empty permittedSu=
btrees is correct, but that restriction only exists for the specific name f=
orm under consideration.<u></u><u></u></span></p><p class=3D"MsoNormal"><sp=
an style=3D"font-size:11pt"><u></u>=C2=A0<u></u></span></p><p class=3D"MsoN=
ormal"><span style=3D"font-size:11pt">> </span>It seems that what we hav=
e to do instead is specify e.g. alice123.mesh=C2=A0in permitted trees and t=
hen exclude every other name type explicitly.=C2=A0<u></u><u></u></p><p cla=
ss=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">Yes, but even the=
n, the list will be incomplete. Someone could create an arbitrary otherName=
type with their own OID and issue certs with such an otherName in the SAN.=
Also, it is not possible to encode a blanket prohibition on SRVName [1]. W=
hether these limitations manifest in a concrete issue for client software i=
s dependent on whether they support such name forms (or handle unknown name=
forms in a dangerous manner).<u></u><u></u></span></p><p class=3D"MsoNorma=
l"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u></span></p><p class=
=3D"MsoNormal"><span style=3D"font-size:11pt">[1] <a href=3D"https://mailar=
chive.ietf.org/arch/msg/pkix/_B_-huGzs217NQqoR4Kk5_lqOh0/" target=3D"_blank=
">https://mailarchive.ietf.org/arch/msg/pkix/_B_-huGzs217NQqoR4Kk5_lqOh0/</=
a><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"><spa=
n style=3D"font-size:11pt">Corey<u></u><u></u></span></p><p class=3D"MsoNor=
mal"><span style=3D"font-size:11pt"><u></u>=C2=A0<u></u></span></p><div sty=
le=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:Calibri,sans-serif">From:</span></b><s=
pan style=3D"font-size:11pt;font-family:Calibri,sans-serif"> Phillip Hallam=
-Baker <<a href=3D"mailto:[email protected]" target=3D"_blank">phill=
@hallambaker.com</a>> <br><b>Sent:</b> Friday, November 15, 2024 4:10 PM=
<br><b>To:</b> Corey Bonnell <<a href=3D"mailto:[email protected]=
om" target=3D"_blank">[email protected]</a>><br><b>Cc:</b> <a h=
ref=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br><b>Subj=
ect:</b> Re: [pkix] Re: Name constraints in certificates<u></u><u></u></spa=
n></p></div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p><div><div><div><=
p class=3D"MsoNormal">My plan would be to constrain the intermediates to is=
sue certificates with subject alt names in the corresponding callsign domai=
n and nothing else, no IP address certs.<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 can't see the value of the callsign CA issuing SRVName certs as the c=
oncept is that it is a purely deterministic system where the quorum of thre=
shold-signers create intermediate certs according to the entries in the cal=
lsign binding that delegate control over that name to a party determined by=
the callsign holder.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u=
></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">I guess you are war=
ning me about 3280<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></=
u>=C2=A0<u></u></p></div><div><pre style=3D"break-before:page"><a href=3D"h=
ttps://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.11" target=3D"_blank"><=
b><span style=3D"color:black">4.2.1.11</span></b></a><span class=3D"m_20414=
60895052691502gmail-h5"><b><span style=3D"color:black">=C2=A0 Name Constrai=
nts</span></b></span><span style=3D"color:black"><u></u><u></u></span></pre=
><pre style=3D"break-before:page"><span class=3D"m_2041460895052691502gmail=
-h5"><b><span style=3D"color:black">...</span></b></span><span style=3D"col=
or:black"><u></u><u></u></span></pre></div><div><pre style=3D"break-before:=
page"><span style=3D"color:black">Restrictions apply only when the specifie=
d name form is present.<u></u><u></u></span></pre><pre style=3D"break-befor=
e:page"><span style=3D"color:black">If no name of the type is in the certif=
icate, the certificate is <u></u><u></u></span></pre><pre style=3D"break-be=
fore:page"><span style=3D"color:black">acceptable<u></u><u></u></span></pre=
></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u></u></p></div><div><p cl=
ass=3D"MsoNormal">Ugh..<u></u><u></u></p></div><div><p class=3D"MsoNormal">=
<u></u>=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">Not much better i=
n 5280:<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=C2=A0<u>=
</u></p></div><div><pre style=3D"break-before:page"><a href=3D"https://www.=
rfc-editor.org/rfc/rfc5280#section-4.2.1.10" target=3D"_blank"><b><span sty=
le=3D"color:black">4.2.1.10</span></b></a><span class=3D"m_2041460895052691=
502gmail-h5"><b><span style=3D"color:black">.=C2=A0 Name Constraints</span>=
</b></span><span style=3D"color:black"><u></u><u></u></span></pre><pre styl=
e=3D"break-before:page"><span style=3D"color:black"><u></u>=C2=A0<u></u></s=
pan></pre></div><div><p class=3D"MsoNormal">I have been looking=C2=A0and ca=
nnot see normative language describing=C2=A0the interpretation of permitted=
subtrees anywhere. What=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoN=
ormal">I would have expected is that if the permitted subtrees is non-empty=
, certificates can only be issued if they are in permitted=C2=A0trees and n=
ot in excluded.<u></u><u></u></p></div><div><p class=3D"MsoNormal"><u></u>=
=C2=A0<u></u></p></div><div><p class=3D"MsoNormal">It seems that what we ha=
ve to do instead is specify e.g. alice123.mesh=C2=A0in permitted trees and =
then exclude every other name type explicitly.=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"><u></u>=C2=A0<u></u></p><div><div><p class=3D"MsoNormal">On =
Fri, Nov 15, 2024 at 3:33<span style=3D"font-family:Arial,sans-serif">=E2=
=80=AF</span>PM Corey Bonnell <<a href=3D"mailto:Corey.Bonnell@digicert.=
com" target=3D"_blank">[email protected]</a>> wrote:<u></u><u><=
/u></p></div><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:5pt 0in 5pt 4.8pt"><div><div><div><p class=3D"MsoNormal"><span style=
=3D"font-size:11pt">Hi Phill,</span><u></u><u></u></p><p class=3D"MsoNormal=
"><span style=3D"font-size:11pt">At the very least, you will want iPAddress=
constraints included as well, otherwise the local CA could issue end-entit=
y certificates for any arbitrary IP address that would be trusted by relyin=
g parties. You may also want constraints on other name forms (e.g., SRVName=
otherNames), depending on the support for such name forms in client softwa=
re you are targeting.</span><u></u><u></u></p><p class=3D"MsoNormal"><span =
style=3D"font-size:11pt">=C2=A0</span><u></u><u></u></p><p class=3D"MsoNorm=
al"><span style=3D"font-size:11pt">Thanks,</span><u></u><u></u></p><p class=
=3D"MsoNormal"><span style=3D"font-size:11pt">Corey</span><u></u><u></u></p=
><p class=3D"MsoNormal"><span style=3D"font-size:11pt">=C2=A0</span><u></u>=
<u></u></p><div style=3D"border-right:none;border-bottom:none;border-left:n=
one;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:Calibri,sans-serif"=
>From:</span></b><span style=3D"font-size:11pt;font-family:Calibri,sans-ser=
if"> Phillip Hallam-Baker <</span><a href=3D"mailto:[email protected]=
m" target=3D"_blank"><span style=3D"font-size:11pt;font-family:Calibri,sans=
-serif">[email protected]</span></a><span style=3D"font-size:11pt;font-=
family:Calibri,sans-serif">> <br><b>Sent:</b> Friday, November 15, 2024 =
2:21 PM<br><b>To:</b> </span><a href=3D"mailto:[email protected]" target=3D"_bl=
ank"><span style=3D"font-size:11pt;font-family:Calibri,sans-serif">pkix@iet=
f.org</span></a><span style=3D"font-size:11pt;font-family:Calibri,sans-seri=
f"><br><b>Subject:</b> [pkix] Re: Name constraints in certificates</span><u=
></u><u></u></p></div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p><div><=
div><div><p class=3D"MsoNormal">Ooops,=C2=A0<u></u><u></u></p></div><div><p=
class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNorm=
al">* Trust=C2=A0the LetsAuthenticate root<u></u><u></u></p></div><div><p c=
lass=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal=
">Oh and, yes, I applied for the names before LetsEncrypt though to apply f=
or a trademark. My thought being that at some point, we might decide we nee=
ded to avoid the provision of WebPKI certs becoming a monopoly.<u></u><u></=
u></p></div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div>=
<p class=3D"MsoNormal">On the ugliness=C2=A0of direct names, it is quite po=
ssible this can be hidden behind hypertext links. I was just experimenting =
with the user 'device browser' and the user doesn't need to kno=
w the camera in their garage is garage-camera.<span style=3D"font-size:11pt=
;font-family:Calibri,sans-serif">mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4.mesh</s=
pan><u></u><u></u></p></div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u=
></p></div><div><p class=3D"MsoNormal">Where this goes pear shaped is if Al=
ice stays at Bob's house and Bob wants to delegate control over stuff w=
hile she is there.<u></u><u></u></p></div><div><p class=3D"MsoNormal">=C2=
=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u>=
</p></div></div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p><div><div><p=
class=3D"MsoNormal">On Fri, Nov 15, 2024 at 12:50<span style=3D"font-famil=
y:Arial,sans-serif">=E2=80=AF</span>PM Phillip Hallam-Baker <<a href=3D"=
mailto:[email protected]" target=3D"_blank">[email protected]</a>&g=
t; wrote:<u></u><u></u></p></div><blockquote style=3D"border-top:none;borde=
r-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padd=
ing:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt"><div><div><p class=3D"MsoNorm=
al">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' :-)<u></u><u></u></p></div><d=
iv><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"Ms=
oNormal">As it happens, I own the domains <a href=3D"http://letsauthenticat=
e.com" target=3D"_blank">letsauthenticate.com</a> and <a href=3D"http://let=
sauthenticate.org" target=3D"_blank">letsauthenticate.org</a> and these cou=
ld be used to create a sister service to letsencrypt but focused on devices=
and issuing certificates that are bound to non-IANA DNS names.<u></u><u></=
u></p></div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div>=
<p class=3D"MsoNormal">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 se=
t of entities=C2=A0holding=C2=A0 the signature keys. So it takes more than =
one party to defect for a bogus certificate to issue.<u></u><u></u></p></di=
v><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=
=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">Th=
e basic plan is that Alice registers the UDF fingerprint of her Mesh root o=
f trust=C2=A0<span style=3D"font-size:11pt;font-family:Calibri,sans-serif">=
mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4 with the=C2=A0</span>LetsAuthenticate th=
reshold CA issues an Intermediate cert to her with a name constraint allowi=
ng her to issue certs in the *.<span style=3D"font-size:11pt;font-family:Ca=
libri,sans-serif">mb5s-r4aj-3fbt-7nho-t26z-2e6y-wfh4.mesh domain.</span><u>=
</u><u></u></p></div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></=
div><div><p class=3D"MsoNormal">Alice can now issue certificates through he=
r local CA which could again make use of threshold to provide separation of=
duties between her local device and an offsite service.<u></u><u></u></p><=
/div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p clas=
s=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">T=
he resulting certificates would be recognized by any Web browser that had t=
he specific configuration to recognize them:<u></u><u></u></p></div><div><p=
class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNorm=
al">* Refer requests for .mesh to a resolver that handles them<u></u><u></u=
></p></div><div><p class=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">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">No=
w 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 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).<u></u><u></u></p></div><div><p cl=
ass=3D"MsoNormal">=C2=A0<u></u><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 solutio=
n for that as well, as most of you know. And building a friendly name regis=
tration service like callsign might be the way to fund this infrastructure =
if it becomes widely=C2=A0used.<u></u><u></u></p></div><div><p class=3D"Mso=
Normal">=C2=A0<u></u><u></u></p></div><div><p class=3D"MsoNormal">=C2=A0<u>=
</u><u></u></p></div><div><p class=3D"MsoNormal">In the short term, I am so=
mewhat concerned about the risk of unexpected effects in the legacy WebPKI.=
I will mark the name constraints critical of course. But would there be co=
nsequences if the user installs the LetsAuthenticate root?<u></u><u></u></p=
></div><div><p class=3D"MsoNormal">=C2=A0<u></u><u></u></p></div><div><p cl=
ass=3D"MsoNormal">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 rea=
lly certs.<u></u><u></u></p></div></div></blockquote></div></div></div></di=
v></div></blockquote></div></div></div></div></div></blockquote></div>
--0000000000003f72650627465367--
--===============2627598877212143887==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls
aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv
IHBraXgtbGVhdmVAaWV0Zi5vcmcK
--===============2627598877212143887==--