[pkix] Re: Name constraints in certificates
Corey Bonnell <[email protected]> Fri, 15 Nov 2024 22:35:06 +0000
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <DS0PR14MB6216D2CAF1E549AFDE40096992242@DS0PR14MB6216.namprd14.prod.outlook.com> |
--===============5206724053155176151== Content-Language: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_05FE_01DB3784.AB6ADE40" ------=_NextPart_000_05FE_01DB3784.AB6ADE40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05FF_01DB3784.AB6ADE40" ------=_NextPart_001_05FF_01DB3784.AB6ADE40 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > I guess you are warning me about 3280 =20 Yes. =20 > 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. =20 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. =20 What you say about non-empty permittedSubtrees is correct, but that = restriction only exists for the specific name form under consideration. =20 > 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.=20 =20 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). =20 [1] = https://mailarchive.ietf.org/arch/msg/pkix/_B_-huGzs217NQqoR4Kk5_lqOh0/ =20 Thanks, Corey =20 From: Phillip Hallam-Baker <[email protected]>=20 Sent: Friday, November 15, 2024 4:10 PM To: Corey Bonnell <[email protected]> Cc: [email protected] Subject: Re: [pkix] Re: Name constraints in certificates =20 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. =20 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. =20 I guess you are warning me about 3280 =20 <https://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.11> 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=20 acceptable =20 Ugh.. =20 Not much better in 5280: =20 <https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10> 4.2.1.10. = Name Constraints =20 I have been looking and cannot see normative language describing the = interpretation of permitted subtrees anywhere. What=20 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. =20 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.=20 =20 =20 On Fri, Nov 15, 2024 at 3:33=E2=80=AFPM Corey Bonnell = <[email protected] <mailto:[email protected]> > 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 = also want constraints on other name forms (e.g., SRVName otherNames), = depending on the support for such name forms in client software you are = targeting. =20 Thanks, Corey =20 From: Phillip Hallam-Baker < <mailto:[email protected]> = [email protected]>=20 Sent: Friday, November 15, 2024 2:21 PM To: <mailto:[email protected]> [email protected] Subject: [pkix] Re: Name constraints in certificates =20 Ooops,=20 =20 * Trust the LetsAuthenticate root =20 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. =20 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 =20 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. =20 =20 =20 On Fri, Nov 15, 2024 at 12:50=E2=80=AFPM Phillip Hallam-Baker = <[email protected] <mailto:[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' :-) =20 As it happens, I own the domains letsauthenticate.com = <http://letsauthenticate.com> and letsauthenticate.org = <http://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. =20 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. =20 =20 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. =20 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. =20 =20 The resulting certificates would be recognized by any Web browser that = had the specific configuration to recognize them: =20 * Refer requests for .mesh to a resolver that handles them * Trust the LetsEncrypt root * Perform the appropriate pathmath to check the end entity cert. =20 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). =20 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. =20 =20 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? =20 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. ------=_NextPart_001_05FF_01DB3784.AB6ADE40 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dutf-8"> <meta name=3DGenerator content=3D"Microsoft Word 15 (filtered = medium)"><style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:"Yu Gothic"; panose-1:2 11 4 0 0 0 0 0 0 0;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Aptos;} @font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2 4;} @font-face {font-family:"\@Yu Gothic"; panose-1:2 11 4 0 0 0 0 0 0 0;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} pre {mso-style-priority:99; mso-style-link:"HTML Preformatted Char"; margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted"; font-family:Consolas; mso-ligatures:none;} span.gmail-h5 {mso-style-name:gmail-h5;} span.EmailStyle22 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} --></style><!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue = vlink=3Dpurple style=3D'word-wrap:break-word'><div = class=3DWordSection1><p class=3DMsoNormal><span = style=3D'font-size:11.0pt'>> </span>I guess you are warning me about = 3280<o:p></o:p></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt'>Yes.<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt'>> </span>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.<o:p></o:p></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt'>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.<o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt'>What you say about = non-empty permittedSubtrees is correct, but that restriction only exists = for the specific name form under consideration.<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt'>> </span>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. <o:p></o:p></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt'>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).<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span style=3D'font-size:11.0pt'>[1] <a = href=3D"https://mailarchive.ietf.org/arch/msg/pkix/_B_-huGzs217NQqoR4Kk5_= lqOh0/">https://mailarchive.ietf.org/arch/msg/pkix/_B_-huGzs217NQqoR4Kk5_= lqOh0/</a><o:p></o:p></span></p><p class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt'>Thanks,<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt'>Corey<o:p></o:p></span></p><p = class=3DMsoNormal><span = style=3D'font-size:11.0pt'><o:p> </o:p></span></p><div = style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in'><p class=3DMsoNormal><b><span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span><= /b><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'> = Phillip Hallam-Baker <[email protected]> <br><b>Sent:</b> = Friday, November 15, 2024 4:10 PM<br><b>To:</b> Corey Bonnell = <[email protected]><br><b>Cc:</b> = [email protected]<br><b>Subject:</b> Re: [pkix] Re: Name constraints in = certificates<o:p></o:p></span></p></div><p = class=3DMsoNormal><o:p> </o:p></p><div><div><div><p = class=3DMsoNormal>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.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>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.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p class=3DMsoNormal>I = guess you are warning me about 3280<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><pre = style=3D'break-before:page'><a = href=3D"https://www.rfc-editor.org/rfc/rfc3280#section-4.2.1.11"><b><span= style=3D'color:black'>4.2.1.11</span></b></a><span = class=3Dgmail-h5><b><span style=3D'color:black'>=C2=A0 Name = Constraints</span></b></span><span = style=3D'color:black'><o:p></o:p></span></pre><pre = style=3D'break-before:page'><span class=3Dgmail-h5><b><span = style=3D'color:black'>...</span></b></span><span = style=3D'color:black'><o:p></o:p></span></pre></div><div><pre = style=3D'break-before:page'><span style=3D'color:black'>Restrictions = apply only when the specified name form is = present.<o:p></o:p></span></pre><pre style=3D'break-before:page'><span = style=3D'color:black'>If no name of the type is in the certificate, the = certificate is <o:p></o:p></span></pre><pre = style=3D'break-before:page'><span = style=3D'color:black'>acceptable<o:p></o:p></span></pre></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>Ugh..<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>Not much better in 5280:<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><pre = style=3D'break-before:page'><a = href=3D"https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.10"><b><span= style=3D'color:black'>4.2.1.10</span></b></a><span = class=3Dgmail-h5><b><span style=3D'color:black'>.=C2=A0 Name = Constraints</span></b></span><span = style=3D'color:black'><o:p></o:p></span></pre><pre = style=3D'break-before:page'><span = style=3D'color:black'><o:p> </o:p></span></pre></div><div><p = class=3DMsoNormal>I have been looking and cannot see normative = language describing the interpretation of permitted subtrees = anywhere. What <o:p></o:p></p></div><div><p class=3DMsoNormal>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.<o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div><div><p = class=3DMsoNormal>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. <o:p></o:p></p></div><div><p = class=3DMsoNormal><o:p> </o:p></p></div></div><p = class=3DMsoNormal><o:p> </o:p></p><div><div><p class=3DMsoNormal>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:[email protected]">[email protected]</a>= > wrote:<o:p></o:p></p></div><blockquote = style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in = 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5= .0pt'><div><div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = style=3D'font-size:11.0pt'>Hi Phill,</span><o:p></o:p></p><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = style=3D'font-size:11.0pt'>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 also want constraints on other name = forms (e.g., SRVName otherNames), depending on the support for such name = forms in client software you are targeting.</span><o:p></o:p></p><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = style=3D'font-size:11.0pt'> </span><o:p></o:p></p><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = style=3D'font-size:11.0pt'>Thanks,</span><o:p></o:p></p><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = style=3D'font-size:11.0pt'>Corey</span><o:p></o:p></p><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span = style=3D'font-size:11.0pt'> </span><o:p></o:p></p><div = style=3D'border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in = 0in 0in'><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span><= /b><span style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'> = Phillip Hallam-Baker <</span><a href=3D"mailto:[email protected]" = target=3D"_blank"><span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>phill@hallamb= aker.com</span></a><span = style=3D'font-size:11.0pt;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"_blank"><span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>[email protected]= </span></a><span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'><br><b>Subjec= t:</b> [pkix] Re: Name constraints in = certificates</span><o:p></o:p></p></div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p><div><div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Ooops, = <o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* = Trust the LetsAuthenticate root<o:p></o:p></p></div><div><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>mb5s-r4aj-3fb= t-7nho-t26z-2e6y-wfh4.mesh</span><o:p></o:p></p></div><div><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div></div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p><div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Fri, Nov = 15, 2024 at 12:50<span = style=3D'font-family:"Arial",sans-serif'>=E2=80=AF</span>PM Phillip = Hallam-Baker <<a href=3D"mailto:[email protected]" = target=3D"_blank">[email protected]</a>> = wrote:<o:p></o:p></p></div><blockquote = style=3D'border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in = 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5= .0pt'><div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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' :-)<o:p></o:p></p></div><div><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>As it = happens, I own the domains <a href=3D"http://letsauthenticate.com" = target=3D"_blank">letsauthenticate.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.<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The basic = plan is that Alice registers the UDF fingerprint of her Mesh root of = trust <span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>mb5s-r4aj-3fb= t-7nho-t26z-2e6y-wfh4 with the </span>LetsAuthenticate threshold CA = issues an Intermediate cert to her with a name constraint allowing her = to issue certs in the *.<span = style=3D'font-size:11.0pt;font-family:"Calibri",sans-serif'>mb5s-r4aj-3fb= t-7nho-t26z-2e6y-wfh4.mesh domain.</span><o:p></o:p></p></div><div><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The = resulting certificates would be recognized by any Web browser that had = the specific configuration to recognize = them:<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* Refer = requests for .mesh to a resolver that handles = them<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* = Trust the LetsEncrypt root<o:p></o:p></p></div><div><p = class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>* Perform = the appropriate pathmath to check the end entity = cert.<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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).<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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?<o:p></o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p><= /o:p></p></div><div><p class=3DMsoNormal = style=3D'mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p></div></div></blockquote></div></div></div></div></d= iv></blockquote></div></div></div></body></html> ------=_NextPart_001_05FF_01DB3784.AB6ADE40-- ------=_NextPart_000_05FE_01DB3784.AB6ADE40 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQXzCCA5Yw ggJ+oAMCAQICEAuTHDrWOWfqZyO/w6+a9EswDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UE AxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IEcyMB4XDTEzMDgwMTEyMDAwMFoXDTM4MDExNTEy MDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IEcyMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2ecoL1I/NnJJiJM08/hqHjFUgJ+tVEG1R9+WqNSv gC25Cs91/YmlfST64yIMK7yVFwszvxlNQQaQAL0MTRD+B7XnHG4iVTFll73TF9IeYvPb6mxQjD+E DJbPt8sD4MptoRRMG4nd7QCwUnyvkWyxOBPR6RIIwACwHCsR2ndwNpuuznmH3IJw5gl0cFVpr6No n7/dtnmz8p1wKVX0q/+VYfPJQG8d0b6Tu9OIKrudv3JaVnE7P9Tz0Qr+KO+j7tmZrwPTj2C38pKh sb2JiR8wzcOmLmIzrhYCd0Ra54EKPKdELnm4PwS8XKCH4RuvUY7N7Cz6+P5t8Dp8qovkZ5UxjQID AQABo0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUzsNKuZlV 8rjbYL+pfr1WtZc2p9YwDQYJKoZIhvcNAQELBQADggEBAMqlVYzjyEFuaSendRHvPIY2b9Kdxng4 HWmWopJpLjhsm30E1ImlsTE3iskhzKtszYscmta/SNIyZsGKwPMvOu/A49SRhtFQ4wPbc3dvSjlT 7d4mx7V9rytC0XVi40orAsdQS+Bp4pZsDkRmEESPrQXr+HmsphvoNzSdU8lhqqJSr0pwFobCOsix E3A22M/u9Ao01VtM/QecorrZAXJc803B3Q6xHA3EY76t9BT7ieyiQQ5MzMhXQNBuA6rNDI6JmZls 8Dwwrzjfb7yjvikgJ6t0/xMieN6XUlUeg7VUIAPursBPVt43zMN/qgQnu9N3uGLbF3ycKCITc2zP JvWKKecwggYfMIIFB6ADAgECAhADuA0Dc6a64oQdstGwJ3SrMA0GCSqGSIb3DQEBCwUAMGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBHMjAeFw0xOTA2MDQxMjM2MjBa Fw0yOTA2MDQxMjM2MjBaMG8xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5EaWdpQ2VydCwgSW5jLjFH MEUGA1UEAxM+RGlnaUNlcnQgUEtJIFBsYXRmb3JtIEMyIFNoYXJlZCBTTUlNRSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmay8IyCiMMl3l gLo6BSrdLBKvx0U1KZR/8PzvS/rsZDBQJLuVgmOTaBxUrNqo9WtejI9me5HihbHKE9BtydcyC8f+ 8cOQOX3hOjs0SZr2P9eXAR8SWf0p/Q/1NkYRorjjPo4z0RovEnX/cl0of7Cny0fW65tMBt/exaxQ Tso6Ea1iRF9U8bf6ZsFkevsNt1WKSY9X/QvWUhfoZb4fsoa8JUZkJMzb12wS/cLnWhaO5G7cqZ+E 2KqhuqlPCrlUGFNVuaPcGsuZRy2X1ByMgA4VIIwNNG0RlPa+KSqpixO6RK7kWTlt5BGhgtKw7Mnu DcLtM2BcSyaPIEqZnapn5qf7AgMBAAGjggK/MIICuzAdBgNVHQ4EFgQU3LcfIDF0S5Qadq2Dgq34 xqPwRF8wHwYDVR0jBBgwFoAUzsNKuZlV8rjbYL+pfr1WtZc2p9YwDgYDVR0PAQH/BAQDAgGGMEwG A1UdJQRFMEMGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBAYKKwYBBAGCNxQCAgYKKwYB BAGCNwoDDAYJKoZIhvcvAQEFMBIGA1UdEwEB/wQIMAYBAf8CAQAwNAYIKwYBBQUHAQEEKDAmMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0 dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwOqA4oDaG NGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RHMi5jcmwwggEi BgNVHSAEggEZMIIBFTCCAREGCWCGSAGG/WwFAjCCAQIwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3 LmRpZ2ljZXJ0LmNvbS9DUFMwgdUGCCsGAQUFBwICMIHIDIHFQW55IHVzZSBvZiB0aGlzIENlcnRp ZmljYXRlIGNvbnN0aXR1dGVzIGFjY2VwdGFuY2Ugb2YgdGhlIERpZ2lDZXJ0IENQL0NQUyBhbmQg UmVseWluZyBQYXJ0eSBBZ3JlZW1lbnQgd2hpY2ggbGltaXQgbGlhYmlsaXR5IGFuZCBhcmUgaW5j b3Jwb3JhdGVkIGhlcmVpbiBieSByZWZlcmVuY2UuIGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9y cGEtdWEwJwYDVR0RBCAwHqQcMBoxGDAWBgNVBAMTD0RpZ2lDZXJ0UEtJLTMtMjANBgkqhkiG9w0B AQsFAAOCAQEAFTczZjttMnThPMxQyeeuZ/VeQHCNNqxCze644O19xXE0Wt3qBx1VRU/QdL4kPtAW vg9sMHhQtLvp9ySna4uF5+ffFQeHUbX12yBrfmgATdKHP2noPeyVCXnculSqsF/F/854dBW9Z1jf Mtvxp/qbTPOf9d5d1mxt+mJ4sDfvd0wl3U2wVCJMUbSXjs8alHeU6ematIwXios5sn2cQcIpMtm/ ySjYvhh4G1DMUrQdpJZTBovuXh8yA3Urq8ZgmBd6mzem450LB48fa6TQyRUZJfr26Ke8EOrBEKLo vi+iTCMQbQsR+4TEsJlJBPemkwqpcfI4V3GVYQjq63ECC2ftATCCBp4wggWGoAMCAQICEE7YikkQ 3vbExnbchx59/aowDQYJKoZIhvcNAQELBQAwbzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDkRpZ2lD ZXJ0LCBJbmMuMUcwRQYDVQQDEz5EaWdpQ2VydCBQS0kgUGxhdGZvcm0gQzIgU2hhcmVkIFNNSU1F IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTAeFw0yMzA4MzAwMDAwMDBaFw0yNTA4MjkyMzU5NTla MFAxFjAUBgNVBAMMDUNvcmV5IEJvbm5lbGwxFjAUBgNVBAoMDURpZ2ljZXJ0LCBJbmMxHjAcBgNV BGETFU5UUlVTK1VULTUyOTk1MzctMDE0MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AMohXmJe3PpUFr7S8e56dpc3bdMSdFZKQSvsC57+oH0BZ22yykRfQ/706gN4pg+YKI2FCPuP10VW 9zT/oy3dFAtjDkJHi094BZVuMEx4AJush10maHDESv2ER2v4l5SIkt9GnzcRpmKpSKzL53TNEG2k 9sJG03ZvkW0R5qgafEeOjcd+Nh9UCzxpd4KG/BY8GEmxb2tRnxRbc5Algio4PbHCM2mOxDAsqCCF 3Lb69J0CtLe+VEx6ujRnHm/4LhkRlbCOb93MxJlHyRJBc/ao9FnLdFYhAICdGA7sf75WN/StyEVX OOtKnuZ5iZ6jXbJeSicvH8UnJc0DzQ5BsNdhGl8CAwEAAaOCA1MwggNPMAwGA1UdEwEB/wQCMAAw DgYDVR0PAQH/BAQDAgWgMBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMCUGA1UdEQQeMByBGkNvcmV5 LkJvbm5lbGxAZGlnaWNlcnQuY29tMIIBIAYDVR0gBIIBFzCCARMwggEPBgdngQwBBQMBMIIBAjAo BggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCB1QYIKwYBBQUHAgIwgcgM gcVBbnkgdXNlIG9mIHRoaXMgQ2VydGlmaWNhdGUgY29uc3RpdHV0ZXMgYWNjZXB0YW5jZSBvZiB0 aGUgRGlnaUNlcnQgQ1AvQ1BTIGFuZCBSZWx5aW5nIFBhcnR5IEFncmVlbWVudCB3aGljaCBsaW1p dCBsaWFiaWxpdHkgYW5kIGFyZSBpbmNvcnBvcmF0ZWQgaGVyZWluIGJ5IHJlZmVyZW5jZS4gaHR0 cHM6Ly93d3cuZGlnaWNlcnQuY29tL3JwYS11YTBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vcGtp LWNybC5zeW1hdXRoLmNvbS9jYV80YjVkNWZkM2IyNjUxYjM1MjI5MGUzNjQ2YWJjYzAwMS9MYXRl c3RDUkwuY3JsMH8GCCsGAQUFBwEBBHMwcTAoBggrBgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLmRp Z2ljZXJ0LmNvbTBFBggrBgEFBQcwAoY5aHR0cDovL2NhY2VyLnN5bWF1dGguY29tL21wa2kvZGln aWNlcnRjMnNoYXJlZHNtaW1lY2EuY3J0MB8GA1UdIwQYMBaAFNy3HyAxdEuUGnatg4Kt+Maj8ERf MEIGCSqGSIb3DQEJDwQ1MDMwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBFjAL BglghkgBZQMEASowLQYKYIZIAYb4RQEQAwQfMB0GE2CGSAGG+EUBEAECAgEBhMvbjkgWBjk1MjI2 ODA5BgpghkgBhvhFARAFBCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpi MjA9MB0GA1UdDgQWBBS1gtIKsvKQBW/e64mfn0gfHw3WkzANBgkqhkiG9w0BAQsFAAOCAQEARlfY ejeBkYhtyRofyvvIlJKGRYOVhIhmteRUoqNadUUIQm0tbGNwupf/weMbR/FFyPwFPkP0VQt4Wjg9 Z76zU4gGzxoCRL/oYiRVM0j80nkLD6f5kb972KtmP+sU8Gr5JIzwKIwBpL+g5+qGILH9wn5ZrUoV 8iQmLIMhXmoRGnlMAH0zn/bDQTJbQhzIRPCVUK1IbCVY7gi0b2wW10G5YQsLs/qZnC17n0VMiyey jRym4zvU2phSbpTKij0toytTJH4Bov83gGQeEID3NoWghEDXZKRAuGUfRlVeuo121if6izXR2FEb 0xYSpj6GsJG4msjd5S2S3TBN3ErkWre9HzGCA9IwggPOAgEBMIGDMG8xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5EaWdpQ2VydCwgSW5jLjFHMEUGA1UEAxM+RGlnaUNlcnQgUEtJIFBsYXRmb3JtIEMy IFNoYXJlZCBTTUlNRSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ECEE7YikkQ3vbExnbchx59/aow CQYFKw4DAhoFAKCCAiMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MjQxMTE1MjIzNDQ4WjAjBgkqhkiG9w0BCQQxFgQUexh5RSt1I7G1whBsp7+1hCsVVpAwgZMGCSqG SIb3DQEJDzGBhTCBgjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCG SAFlAwQBAjAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAhowCwYJYIZIAWUD BAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwgZQGCSsGAQQBgjcQBDGBhjCBgzBvMQswCQYD VQQGEwJVUzEXMBUGA1UEChMORGlnaUNlcnQsIEluYy4xRzBFBgNVBAMTPkRpZ2lDZXJ0IFBLSSBQ bGF0Zm9ybSBDMiBTaGFyZWQgU01JTUUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBAhBO2IpJEN72 xMZ23Iceff2qMIGWBgsqhkiG9w0BCRACCzGBhqCBgzBvMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO RGlnaUNlcnQsIEluYy4xRzBFBgNVBAMTPkRpZ2lDZXJ0IFBLSSBQbGF0Zm9ybSBDMiBTaGFyZWQg U01JTUUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBAhBO2IpJEN72xMZ23Iceff2qMA0GCSqGSIb3 DQEBAQUABIIBABTszCLExSHrSWZNmKcpTqNc0twolc6aYPHMEhSqMTTW/xedRnsJygT0ydC1DVrd 3R6x7StE+OURwdpRIWwoOJr2SAdua55KcMTE/qDD2lqceo4Tw6WOVr2fUXWEF2/f7VPJlufwRF5U 32V+mJ9/qGEmVP+WC5S2S7VkAKbkU+qy2pWglWlDLUqwhaIHbuZlDLDBDTJQCvf174TAqWc9kbnB APda2iWli5yEm5P42LutTTNtSohfKyRAgQoU955T46PAUs9MKv7ZCSNWH8WAlCD4hEho46OHBt95 +7xjZ0mlFrY5BqtogWtFbapip5PX9MZ9G1fuqEGOyLfqvy7AwycAAAAAAAA= ------=_NextPart_000_05FE_01DB3784.AB6ADE40-- --===============5206724053155176151== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KcGtpeCBtYWls aW5nIGxpc3QgLS0gcGtpeEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IHBraXgtbGVhdmVAaWV0Zi5vcmcK --===============5206724053155176151==--