[Smcwg-public] Bridge CA

Corey Bonnell Corey.Bonnell at digicert.com
Thu Aug 4 13:45:23 UTC 2022


> 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.

 

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.

 

Unfortunately, this “loophole” already exists in the TLS BRs and the SM BRs draft in Section 8.6, which says:

“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.”

 

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.

 

 

From: Martijn Katerbarg <martijn.katerbarg at sectigo.com> 
Sent: Thursday, August 4, 2022 9:22 AM
To: Corey Bonnell <Corey.Bonnell at digicert.com>; SMIME Certificate Working Group <smcwg-public at cabforum.org>; Wendy Brown - QT3LB-C <wendy.brown at gsa.gov>; Stephen Davidson <Stephen.Davidson at digicert.com>
Subject: RE: [Smcwg-public] Bridge CA

 

>> 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

 

>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.

 

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.

 

 

From: Smcwg-public <smcwg-public-bounces at cabforum.org <mailto:smcwg-public-bounces at cabforum.org> > On Behalf Of Corey Bonnell via Smcwg-public
Sent: Thursday, 4 August 2022 15:06
To: Wendy Brown - QT3LB-C <wendy.brown at gsa.gov <mailto:wendy.brown at gsa.gov> >; SMIME Certificate Working Group <smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> >; Stephen Davidson <Stephen.Davidson at digicert.com <mailto:Stephen.Davidson at digicert.com> >
Subject: Re: [Smcwg-public] Bridge CA

 

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.

 

Hi Wendy,

Comments inline.

 

> 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.

 

“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).

 

> 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

 

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.

 

Thanks,

Corey

 

From: Smcwg-public <smcwg-public-bounces at cabforum.org <mailto:smcwg-public-bounces at cabforum.org> > On Behalf Of Wendy Brown - QT3LB-C via Smcwg-public
Sent: Thursday, August 4, 2022 7:48 AM
To: Stephen Davidson <Stephen.Davidson at digicert.com <mailto:Stephen.Davidson at digicert.com> >
Cc: SMIME Certificate Working Group <smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> >
Subject: Re: [Smcwg-public] Bridge CA

 

at least change the definition to

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.

 

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.

 

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.

 

I agree with the first sentence of your closing paragraph:

Bridge CAs fall outside of mandatory adoption of the SBR unless the Bridge CA itself is Publicly-Trusted.  

However, the last sentence is again misleading

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.

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.

 

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.

 

Thanks, (and sorry to be providing what may seem to be too many details for the current discussion)

 

Wendy

 

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services

703-965-2990 (cell)

 

 

On Wed, Aug 3, 2022 at 6:10 PM Stephen Davidson <Stephen.Davidson at digicert.com <mailto:Stephen.Davidson at digicert.com> > wrote:

Hi Wendy – thank you for the suggestion.

 

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.

 

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.

 

Best, Stephen

 

 

From: Wendy Brown - QT3LB-C <wendy.brown at gsa.gov <mailto:wendy.brown at gsa.gov> > 
Sent: Wednesday, August 3, 2022 3:00 PM
To: Stephen Davidson <Stephen.Davidson at digicert.com <mailto:Stephen.Davidson at digicert.com> >; SMIME Certificate Working Group <smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> >
Subject: Re: [Smcwg-public] Bridge CA

 

Stephen - suggested rewording of the Bridge CA definition

 

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.

 




Wendy

 

Wendy Brown

Supporting GSA

FPKIMA Technical Liaison

Protiviti Government Services

703-965-2990 (cell)

 

 

On Wed, Aug 3, 2022 at 12:39 PM Stephen Davidson via Smcwg-public <smcwg-public at cabforum.org <mailto:smcwg-public at cabforum.org> > wrote:

Hello:

 

Following our discussion, I have merged the PR relating to Bridge CAs https://github.com/cabforum/smime/commit/50093055e1a2db9822cc68f90f503b48210f576a <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> 

 

As discussed we will want to add a definition for a Bridge CA.  I propose the following:

 

Bridge CA – A CA that facilitates interoperability between different enterprises or communities that operate their own PKIs, by issuing Cross Certificates to participating CAs. 

 

Feedback welcomed.

 

Regards, Stephen

 

_______________________________________________
Smcwg-public mailing list
Smcwg-public at cabforum.org <mailto:Smcwg-public at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/smcwg-public <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> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220804/7f65d74e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4990 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/smcwg-public/attachments/20220804/7f65d74e/attachment-0001.p7s>


More information about the Smcwg-public mailing list