[Smcwg-public] Bridge CA

Stephen Davidson Stephen.Davidson at digicert.com
Thu Aug 4 22:00:17 UTC 2022


The Bridge CA references have been removed.

https://github.com/cabforum/smime/pull/160/files



Regards, Stephen







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



I agree with Wendy’s initial suggestion that Bridges not be mentioned in the SBR at all.  My recommended language in Section 1.1 was based on the repeated reference to Bridges throughout the document.  However, to that note, if Section 1.1 is going to identify PKI implementations that are out of scope, the language I recommended still stands because in addition to Enterprise PKI that is locally trusted only, there are federated environments that use the Bridge model for interorganizational trust.  As Wendy indicated, each member of the Federation chains to its own Root, not relying on external Roots at all.

Alternative would be to remain silent on out-of-scope and make the statement that only publicly-trusted CAs (CA Chains) are in scope.

On a related note, Bridges are not Roots of Trust, they are best described as trust brokers.  They provide a point of commonality between diverse policy environments.  Bridge governance is a shared activity among the members of the Bridge “federation.”

As to the definition of a cross certificate, X.509 defines a cross certificate as: “CA certificates in which the issuer and subject are different entities.  Cross-certificates describe a trust relationship between the two CAs.”  NIST further narrows this definition to “A certificate issued from a certificate authority (CA) that signs the public key of another CA not within its trust hierarchy that establishes a trust relationship between the two CAs.”  Suggesting a cross-certificate solely describes a relationship between two Roots is a further narrowing of this definition.  The Bridge CA model has been in operation for 20 years.  The term cross-certificate has been used for this entire period to describe the certificate relationship between the Bridge CAs and their enterprise member CAs, thereby becoming a term of art within the larger community.  As previously stated, the Bridge is not a Root CA, nor is there any requirement that the cross-certified Enterprise member CA is a Root.

There are two possible ways forward – one would be to replace the current CAB/F definition of a Root with either the X.509 or the standard NIST definition.  The other would be to modify the CAB/F definition to add “For the purposes of the public-trust environment (or words to that effect). . .” at the beginning of the definition.

Judy



Judith Spencer | PMA Chair | CertiPath, Inc.

1900 Reston Metro Plaza, Suite 303, Reston, VA 20190

PH +1.703.793.7875

Email Judith.Spencer at CertiPath.com<mailto:Judith.Spencer at CertiPath.com>



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, August 4, 2022 9:46 AM
To: Martijn Katerbarg <martijn.katerbarg at sectigo.com<mailto:martijn.katerbarg at sectigo.com>>; SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>; Wendy Brown - QT3LB-C <wendy.brown at gsa.gov<mailto:wendy.brown at gsa.gov>>; Stephen Davidson <Stephen.Davidson at digicert.com<mailto:Stephen.Davidson at digicert.com>>
Subject: Re: [Smcwg-public] Bridge CA



> 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<mailto:martijn.katerbarg at sectigo.com>>
Sent: Thursday, August 4, 2022 9:22 AM
To: Corey Bonnell <Corey.Bonnell at digicert.com<mailto:Corey.Bonnell at digicert.com>>; SMIME Certificate Working Group <smcwg-public at cabforum.org<mailto:smcwg-public at cabforum.org>>; Wendy Brown - QT3LB-C <wendy.brown at gsa.gov<mailto:wendy.brown at gsa.gov>>; Stephen Davidson <Stephen.Davidson at digicert.com<mailto: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/f89e747c/attachment-0001.html>


More information about the Smcwg-public mailing list