<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="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:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:"Segoe Script";
panose-1:3 11 5 4 2 0 0 0 0 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>> <span style='mso-fareast-language:EN-US'>Likewise. It seems like a fairly simple solution. However I’m not sure the Policy OID bit should be in there. It creates a potential loophole for CA’s to issue a certificate chaining up to a root within a public trust program but without containing a Policy OID, and through that way be exempt from the requirements.<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I agree that using the SM BR definition of scope (emailProtection EKU and inclusion of at least one email address in the SAN) would be better than speaking to policy OIDs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Unfortunately, this “loophole” already exists in the TLS BRs and the SM BRs draft in Section 8.6, which says:<o:p></o:p></p><p class=MsoNormal>“The Audit Report SHALL state explicitly that it covers the relevant systems and processes used in the issuance of all Certificates that assert one or more of the policy identifiers listed in Section 7.1.6.1.”<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Hopefully, a CA has never exploited it to exempt systems and processes that should have been in scope under the requirements in Section 8.1.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Martijn Katerbarg <martijn.katerbarg@sectigo.com> <br><b>Sent:</b> Thursday, August 4, 2022 9:22 AM<br><b>To:</b> Corey Bonnell <Corey.Bonnell@digicert.com>; SMIME Certificate Working Group <smcwg-public@cabforum.org>; Wendy Brown - QT3LB-C <wendy.brown@gsa.gov>; Stephen Davidson <Stephen.Davidson@digicert.com><br><b>Subject:</b> RE: [Smcwg-public] Bridge CA<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>>> I would even prefer leaving out all mention of Bridge CAs in the document and instead just make it clear that the document is only applicable to PKIs that adopt them by asserting any of the CAB Forum certificate policy OIDs in certificates they issue and are included in one or more of the public trust programs managed by the member certificate consumers<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>>I like this approach, as it focuses on whether or not a particular CA falls under the scope of these Requirements; the fact of whether a particular CA only certifies other CAs or issues end-entity certificates isn’t particularly relevant to defining the scope.<o:p></o:p></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'>Likewise. It seems like a fairly simple solution. However I’m not sure the Policy OID bit should be in there. It creates a potential loophole for CA’s to issue a certificate chaining up to a root within a public trust program but without containing a Policy OID, and through that way be exempt from the requirements.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-fareast-language:EN-US'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Smcwg-public <<a href="mailto:smcwg-public-bounces@cabforum.org">smcwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Corey Bonnell via Smcwg-public<br><b>Sent:</b> Thursday, 4 August 2022 15:06<br><b>To:</b> Wendy Brown - QT3LB-C <<a href="mailto:wendy.brown@gsa.gov">wendy.brown@gsa.gov</a>>; SMIME Certificate Working Group <<a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a>>; Stephen Davidson <<a href="mailto:Stephen.Davidson@digicert.com">Stephen.Davidson@digicert.com</a>><br><b>Subject:</b> Re: [Smcwg-public] Bridge CA<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div style='border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt 2.0pt'><p class=MsoNormal style='line-height:12.0pt;background:#FAFA03'><span style='font-size:10.0pt;color:black'>CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hi Wendy,<o:p></o:p></p><p class=MsoNormal>Comments inline.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Bridge CA – A CA that facilitates interoperability between different enterprises or communities that operate their own PKIs, through the use of Cross Certificates with participating CAs.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>“Cross Certificate” is a Defined Term within the (SM)BRs that has a narrower meaning than “cross certification” as defined in 5280, namely that it is “A certificate that is used to establish a trust relationship between two Root CAs”. “Root CAs” in this case refers to the CA (name and public key pair) that is distributed by Application Software Suppliers. Given this, I believe the proposed definition is too narrow in that it would not encompass cross-certification of Subordinate CAs (i.e., an issuer and/or subject whose key is not directly distributed by Application Software Suppliers).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> I would even prefer leaving out all mention of Bridge CAs in the document and instead just make it clear that the document is only applicable to PKIs that adopt them by asserting any of the CAB Forum certificate policy OIDs in certificates they issue and are included in one or more of the public trust programs managed by the member certificate consumers<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I like this approach, as it focuses on whether or not a particular CA falls under the scope of these Requirements; the fact of whether a particular CA only certifies other CAs or issues end-entity certificates isn’t particularly relevant to defining the scope.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Smcwg-public <<a href="mailto:smcwg-public-bounces@cabforum.org">smcwg-public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Wendy Brown - QT3LB-C via Smcwg-public<br><b>Sent:</b> Thursday, August 4, 2022 7:48 AM<br><b>To:</b> Stephen Davidson <<a href="mailto:Stephen.Davidson@digicert.com">Stephen.Davidson@digicert.com</a>><br><b>Cc:</b> SMIME Certificate Working Group <<a href="mailto:smcwg-public@cabforum.org">smcwg-public@cabforum.org</a>><br><b>Subject:</b> Re: [Smcwg-public] Bridge CA<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>at least change the definition to<o:p></o:p></p><div><p class=MsoNormal>Bridge CA – A CA that facilitates interoperability between different enterprises or communities that operate their own PKIs, through the use of Cross Certificates with participating CAs.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Because your wording perpetuates the misunderstanding that Bridges are used as the Root for their community, which is not the case. Most Bridges do not make their self-signed certificate available to be used as a trust anchor.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Although Judy may not agree with me, I would even prefer leaving out all mention of Bridge CAs in the document and instead just make it clear that the document is only applicable to PKIs that adopt them by asserting any of the CAB Forum certificate policy OIDs in certificates they issue and are included in one or more of the public trust programs managed by the member certificate consumers.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I agree with the first sentence of your closing paragraph:<o:p></o:p></p></div><div><blockquote style='margin-left:30.0pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal>Bridge CAs fall outside of mandatory adoption of the SBR unless the Bridge CA itself is Publicly-Trusted. <o:p></o:p></p></div></blockquote><p class=MsoNormal>However, the last sentence is again misleading<o:p></o:p></p><blockquote style='margin-left:30.0pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><p class=MsoNormal>If a CA that is crossed with the Bridge CA is itself Publicly-Trusted then it must adopt but it does not drag other nonPublicly-Trusted CAs in the Bridge ecosystem into scope.<o:p></o:p></p></div></blockquote><p class=MsoNormal>That is exactly the issue that was created that resulted in the Symantec issue a number of years ago. Because there was a Symantec Root in the public trust stores that had issued a cross-certificate to the FBCA, people felt that Symantec was therefore responsible for all of the PKIs in the FPKI following all the BRs when in fact many of them did not even issue TLS certificates and would not have created valid paths to that root if the browsers had correctly done certificate policy processing during path validation according to RFC 5280.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Bridges are NOT the root of trust for their community, instead they operate more as a hub, allowing peer PKIs to only have to issue 1 cross-certificate to the Bridge, while the Bridge issues cross-certificates to all the member peer PKIs. This allows each member PKI to use their own Root as a Trust Anchor while enabling them to trust all the other member PKIs. Essentially the Bridge is an intermediate CA between each pair of peer PKIs in the community.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks, (and sorry to be providing what may seem to be too many details for the current discussion)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Segoe Script"'>Wendy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Wendy Brown<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Supporting GSA<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>FPKIMA Technical Liaison<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Protiviti Government Services<o:p></o:p></p><p class=MsoNormal>703-965-2990 (cell)<o:p></o:p></p></div></div></div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, Aug 3, 2022 at 6:10 PM Stephen Davidson <<a href="mailto:Stephen.Davidson@digicert.com">Stephen.Davidson@digicert.com</a>> wrote:<o:p></o:p></p></div><blockquote style='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=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi Wendy – thank you for the suggestion.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I’d like to stick with the original simpler text because the SBR doesn’t address “how a Bridge CA operates” apart from adopting some CABF-wide standards covering Cross Certificate profiles.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Bridge CAs fall outside of mandatory adoption of the SBR unless the Bridge CA itself is Publicly-Trusted. If a CA that is crossed with the Bridge CA is itself Publicly-Trusted then it must adopt but it does not drag other nonPublicly-Trusted CAs in the Bridge ecosystem into scope.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Best, Stephen<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Wendy Brown - QT3LB-C <<a href="mailto:wendy.brown@gsa.gov" target="_blank">wendy.brown@gsa.gov</a>> <br><b>Sent:</b> Wednesday, August 3, 2022 3:00 PM<br><b>To:</b> Stephen Davidson <<a href="mailto:Stephen.Davidson@digicert.com" target="_blank">Stephen.Davidson@digicert.com</a>>; SMIME Certificate Working Group <<a href="mailto:smcwg-public@cabforum.org" target="_blank">smcwg-public@cabforum.org</a>><br><b>Subject:</b> Re: [Smcwg-public] Bridge CA<o:p></o:p></p></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Stephen - suggested rewording of the Bridge CA definition<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Bridge CA – A CA that facilitates interoperability between different enterprises or communities that operate their own PKIs, by issuing and receiving Cross Certificates which map the peer PKI certificate policies to the certificate policies of the Bridge CP.<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br clear=all><o:p></o:p></p><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-family:"Segoe Script"'>Wendy</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Wendy Brown<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Supporting GSA<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>FPKIMA Technical Liaison<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Protiviti Government Services<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>703-965-2990 (cell)<o:p></o:p></p></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Wed, Aug 3, 2022 at 12:39 PM Stephen Davidson via Smcwg-public <<a href="mailto:smcwg-public@cabforum.org" target="_blank">smcwg-public@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='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=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hello:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Following our discussion, I have merged the PR relating to Bridge CAs <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fsmime%2Fcommit%2F50093055e1a2db9822cc68f90f503b48210f576a&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cd8f3b08d2f3742f667d008da761a10ca%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637952151584124831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Wqyj5ssNV0eAviHuTjJyIZBboy719hy97LsTIp7AcPk%3D&reserved=0" target="_blank">https://github.com/cabforum/smime/commit/50093055e1a2db9822cc68f90f503b48210f576a</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>As discussed we will want to add a definition for a Bridge CA. I propose the following:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Bridge CA – A CA that facilitates interoperability between different enterprises or communities that operate their own PKIs, by issuing Cross Certificates to participating CAs. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Feedback welcomed.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Regards, Stephen<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>_______________________________________________<br>Smcwg-public mailing list<br><a href="mailto:Smcwg-public@cabforum.org" target="_blank">Smcwg-public@cabforum.org</a><br><a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fsmcwg-public&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7Cd8f3b08d2f3742f667d008da761a10ca%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637952151584124831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pcgXy3SRB5zt%2BiRfbx%2BpaoHNAGKkFdAbpVxp25BuU7E%3D&reserved=0" target="_blank">https://lists.cabforum.org/mailman/listinfo/smcwg-public</a><o:p></o:p></p></blockquote></div></div></div></blockquote></div></div></div></body></html>