Update policy.md

[dustinhollenback-apple]

V2.0 initial draft

[aarongable]

Are the Baseline Requirements an "external operational standard"? If so, this requirement will cause major issues. Maybe this is a well-known term of art, but I'm not sure how to determine what qualifies as an "external operational standard".

[dustinhollenback-apple]

@aarongable
Thank you for the feedback. Yes, the various Baseline Requirements and the Network Security Requirements were intended to fall into this category. We'll update the policy to provide clarity.

[aarongable]

So the intent is that incorporating the Baseline Requirements by reference will be disallowed, overriding the BR's intent that they be included by reference? And we'll also have to merge all of the various individual (Microsoft, Mozilla, Chrome, etc) root program requirements into our CP/CPS as well?

Forgive me, but that seems untenable. At Let's Encrypt we spent a very long time using automation to build our CP as a diff on top of the BRs, so that we could incorporate all language from upstream directly instead of by reference. This automation was a nightmare to maintain, and it meant that new versions of our CP frequently contained large volumes of irrelevant information (e.g. changes to validation methods that we don't use, but have to be present for the sub-sub-subsection numbering to make sense). The only reason it was even vaguely usable was because we had separate CP and CPS documents at the time, so the CP could contain only normative requirements, while the CPS contained only description of how we complied with those requirements.

In a world where all CAs use a combined CP/CPS, the problems will be even worse. The document will contain both normative requirements (copied and merged from various upstream documents) and non-normative description. Reading the document and understanding the source and purpose of each paragraph will be a nightmare for Subscribers and auditors, and maintaining the document will be a multi-person full-time effort.

We believe strongly that having the CP/CPS maintained by the actual engineering staff doing the work of the CA results in a more accurate, more detailed, and more-adhered-to CP/CPS. Making this document harder to maintain will make it impossible for that duty to be held by engineers, and result in deteriorating the connection between the CP/CPS and actual CA practices.

Please reconsider this "no incorporation by reference" requirement; I truly believe it will make the ecosystem worse, not better.

[dzacharo]

On the same topic, I would like to highlight that, historically, the community accepted the fact that CAs reference external sources like NetSec and EV Guidelines. Especially for the EV Guidelines, due to the prescriptive nature of the validation sections, the community accepted CP/CPS documents with references to specific sections of the EV Guidelines. It's not enough to just say "we follow the EV Guidelines" and be done with it. There are numerous CP/CPS reviews in M.D.S.P. that demonstrate this.

On the other hand, for NetSec, the community was satisfied to see that the CA adheres to the NetSec guidelines.

As a general comment, it makes sense for CAs to expand on areas where a requirement is descriptive, but for the very prescriptive ones, references would make the reading of CP/CPS documents easier.

[aarongable]

Had a chat with Dustin, and now have a much better understanding of the motivation and goal here. As a result, I also have updated suggestions for how to achieve that goal.

The underlying issue here is twofold:

1. CAs whose CPSes have many sections that say "we do what the BRs say".
2. CAs whose CPSes have many sections that reference other external docs, like government standards, TPSes, etc.

The second is a problem for folks who are trying to read a CPS and understand what the CA actually says they're going to do. Jumping around a million documents and following long chains of references makes it hard to tell what behavior the CA is committing to. It makes sense to ask CAs to incorporate these statements directly into their CPS, for easy consumption.

The first problem is, in my opinion, of a very different sort. The issue here is that the BRs are not a CPS.

Fundamentally, a CP is a document that prescribes what the CA MUST or MUST NOT do. The BRs are a CP, the Apple Root Program Requirements are a CP, the Mozilla Root Program Requirements are a CP, other PKIs have their own CPs, etc. Any document that contains MUST/SHALL statements is essentially a CP.

A CPS is a document that describes how the CA complies with its CP. It does not have any MUST/SHALL statements. And there is no overarching CPS for an entire PKI; instead each CA must have their own CPS, because every CA's operations are different.

All of this is a very long way to say that having a CPS which says "we comply with the BRs" is a category error. That's a statement of what you're supposed to do, not a description of how you do it. A CPS which contains such statements is fundamentally not meeting the requirements of a CPS.

So to address the first underlying issue, I think that Apple should instead angle towards having a requirement that CPSes actually contain CPS-style statements. Perhaps something like:

The CPS portions of the combined CP/CPS, i.e. those portions which describe how the CA complies with the requirements laid out in the CP portions of the document, MUST NOT rely on incorporation by reference to external operational standards.

This means that a CA could publish a combined CP/CPS, wherein the "CP portions" are a paragraph near the top stating that the document incorporates by reference all the necessary CPs (the BRs and all the individual root program requirements), and then the remainder of the document can be the "CPS portions" wherein the CA describes how they comply with all of those requirements, without any reliance on incorporation of further external documents.

[aarongable]

Not all CAs issue SMIME certs, and should not be required to stay up to date on communications on this list.

[aarongable]

Please specify how such requests will be made (e.g. to a specific address disclosed in CCADB). Otherwise people may interpret this as putting CAs on the hook even for non-critical emails between CA employees and Apple Root Program representatives.

[aarongable]

Please clarify whether this applies to Cross-Certified Subordinate CA Certificates. I imagine that it does, as those are a subset of all "subordinate CA Certificates", but that makes this requirement noticeably stricter than the BRs requirement (which permits Cross-Certified certificates to retain the same EKUs as the original cert, which may be the empty set if the original was a Root).

[XolphinMartijn]

This does seem like an extension of an already present requirement in the current Apple policy however:

not contain the same public key as any other certificate which asserts any other extendedKeyUsage OIDs.

However, this currently seems to only apply to Single Purpose Root CAs and their SubCAs, where-as this language extends this to any and all SubCAs.

[XolphinMartijn]

Actually @aarongable I believe this new Apple requirement is in line with an existing requirement in the CCADB Policy. See Section 6.3 of that policy, I'm curious if you agree with that assessment

[anttidantti]

So for example Server Authentication and Legacy TLS Apple expects separate CP/CPS to be maintained, or how should we read this requirement?

[anttidantti]

Could you be able to provide practical example what CA-defined could be that Apple would approve?

[dustinhollenback-apple]

Hi @anttidantti ,

Here is an example that I previously shared to a Server Certificate WG discussion:

"This CA conforms to the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates (“TLS BRs”), except for the requirement in BR §7.1.2.3(f) that subscriber certificates include id‑kp‑serverAuth in the ExtendedKeyUsage extension.

Within the hierarchies covered by this document, all CAs that issue subscriber certificates are technically constrained to issue only client‑authentication subscriber certificates. Accordingly, BR §7.1.2.3(f) does not apply to subscriber certificates issued under these hierarchies. Such certificates include id‑kp‑clientAuth and do not assert id‑kp‑serverAuth.

All other applicable provisions of BR §7.1.2.3 and all other applicable sections of the TLS BRs, including identity validation for DNS names and IP addresses, certificate content and SAN requirements, algorithm and key size requirements, KeyUsage requirements, CA certificate profiles, audit requirements, key management, revocation, and CP/CPS publication obligations, are fully met by this CA."

[anttidantti]

Is there something CAs should be aware of because of this recommendation? We're obligated to publish per CCADB policy within 7 days the CA certificate in CCADB, but it may well be so that the CA certificate is used for issuance within 14 days of issuance. Just to be aware if issuance should actually be avoided for that 14 day period after the CCADB disclosure is done.

[dustinhollenback-apple]

Hi @anttidantti,

To ensure certificates function as intended across all Apple devices, the proper sequence is:

1. Sign the new subordinate CA certificate.
2. Disclose it to the CCADB (within 7 days of issuance, as required by CCADB Policy).
3. Wait at least 14 days (as recommended by Apple).
4. Begin issuing certificates from the new subordinate CA.

[anttidantti]

What about use cases outside the Apple recognized Trust Purposes, for example if one has Document Signing use cases supported? Are those to be separated (PKI hierarchies, CP/CPS' etc)?

[dzacharo]

Is it right to assume that existing, multi-purpose Root CAs included in the Apple Root Program will continue to work as they transition to single-purpose hierarchies as re-defined by this new policy?

[wthayer]

For the "legacy" case of serverAuth and clientAuth, this would suggest that the CA must publish two (likely identical) CP/CPS docs? Is that really the intention?

[aww-aww]

SignedHTTPExchange certificates add another variant that is not entirely clear how to handle under the current wording as they are effectively TLS serverAuth, but potentially a different Trust Purpose? While Apple may not support SignedHTTPExchange, participating CAs that do might need to maintain another document that is essentially the same to cover all use cases.

[srdavidson]

From the discussion at the CABF F2F, it sounds like for subCAs created after 2026-07-01 the intent is that "S/MIME" is the Trust Purpose which might incorporate "Secure Email" (id-kp-emailProtection only aka S/MIME BR Strict) or "Legacy S/MIME" (id-kp-emailProtection and id-kp-clientAuth aka a pared down version of S/MIME BR Multipurpose).

• Can S/MIME (ie "Secure Email" and "Legacy S/MIME" as well as pre-existing subCAs) be covered in the same CP/CPS?
• Do "Secure Email" and "Legacy S/MIME" need to issued from separate subCA?
• For earlier subCAs, does the existing broader S/MIME BR Multipurpose still apply?

[wthayer]

I'd suggest adding an effective date for this - for example, our CPS does not list the EKUs in section 1.4 and will need to be updated to meet this requirement.

[dustinhollenback-apple]

@wthayer

Thank you for the feedback. We'll update to include an effective date.

[luisc-sslcom]

For clarification, is the required approval only for externally operated Subordinate CAs?

[dustinhollenback-apple]

@luisc-sslcom

Thank you for the feedback. Yes, that was the intent as well, but the wording could be improved. We will investigate possible changes to add clarity.

[srdavidson]

The S/MIME BR Legacy profiles were deprecated for use in email certs in July 2025 (and there is a Multipurpose set of profiles there). To avoid confusion in this policy, it may be better to say "Multiuse S/MIME" perhaps?

[dzacharo]

I would like to kindly push-back to such requirement without a thorough discussion with CAs and Auditors (WebTrust and ETSI) about the complexities, challenges and legal matters related to the public disclosure of such reports. Without a good definition and description of what a "Detailed Controls Report" should and should not contain, there may be accidental sensitive details disclosed to the public that may affect the security of the CA.

Obviously there is also a cost increase associated with such a requirement.

Apple retains the right to request such a report from any CA in the Apple Root Program. I would like to suggest this right to first be exercised selectively to CAs of interest before requiring it for all CAs in the program.

[dzacharo]

Markdown has certain limitations (tables, images, references), it is not suitable for document processing. A CP/CPS is designed to be written and read by humans, not machines. CAs have compliance teams, systems architects and sometimes legal experts managing those documents. These people don't know how to use Git or write in Markdown.

A large number of CAs typically create their documents in MS Word and publish as PDFs. These are the authoritative versions of the documents. It should be relatively easy for a conversion engine to produce a markdown from those documents, ignoring the problems in formatting and images produced but these should be suitable for machines instead of humans, therefore should not be the authoritative versions.

If the Apple Root Program has a strong position on requiring markdown, I would kindly suggest moving this requirement into a SHOULD for 2027 and a SHALL for 2028. Consider CAs that offer multiple certificate types and must combine those documents. It is a complicated project to combine these in markdown, as recently demonstrated in the BR-of-BRs discussion in the CA/B Forum. Special tooling needs to be developed to accomplish this task.

[dzacharo]

Historically, some Root Programs (Mozilla) has a preference for a single CP/CPS document that governs all EKUs for consolidation of the practices and easier to review for the multiple purposes of the Root Program. Some CAs have also opted-in to a consolidated CP/CPS for improved consistency (one requirement changes and affects all certificates, or another requirement clarifies that "this applies to X-type and that applies to Y-type of certificates".

Most Policies and Practices are the same for different certificate types as demonstrated in the BR-of-BRs work which captured the common language between the various BRs in the CA/B Forum.

Also, most CAs that offer different types use the same controls and practices, usually adopting the strictest of requirements for all types to minimize administrative overhead (using different systems for different certificate types makes it more complex and requires more attention and resources to maintain).

If the Apple Root Program has a strong position on requiring distinct CP/CPS per certificate type (ServerAuth, S/MIME, ClientAuth), I would kindly suggest moving this requirement into a SHOULD for 2027 and a SHALL for 2028

[dzacharo]

Is it right to assume that existing, multi-purpose Root CAs included in the Apple Root Program will continue to work as they transition to single-purpose hierarchies as re-defined by this new policy?

[sandybalzer-sws]

Were the Network and Certificate System Security Requirements intentionally excluded from this list of Baseline Requirements Definitions?

[dustinhollenback-apple]

@sandybalzer-sws , yes, the NCSSRs were intentionally not added as this is redundant. The relevant Baseline Requirements already require adherence to the NCSSRs.

[chrisbn]

What would be the expected treatment of CAs with additional EKUs (for example Microsoft EKUs such as Key Recovery)?

[chrisbn]

The multipurpose SMIME profile currently still permits the use of other EKUs - is it the intention to restrict all non-legacy SMIME profiles to the emailprotection EKU?

[chrisbn]

Trust Purposes "Secure Email" and "Legacy S/MIME" are listed as distinct purposes. This would mean that two separate Root CA hierarchies would be required for different flavors of S/MIME. Is this intentional?

[stefankirch]

The “version in effect at the beginning of the audit period” may not always be appropriate, since the start of the audit period may be a year ago and new versions of the specifications may have been published in the meantime.
Would an “applicable” version perhaps be better?

[srdavidson]

Per the discussion at the CABF F2F, the long held understanding of the SMCWG was that a leaf cert that did not have emailProtection EKU + rfc822name/othername in SAN is not an S/MIME and not subject to the S/MIME BR as stated in section 1.1 of the standard.
From that CABF discussion, it has become clear that the Apple emphasis now is that a subCA carrying the emailProtection EKU is considered S/MIME and that all leaf certs from those subCAs must include at last one rfc822name, thereby making all leafs carrying emailProtection subject to the S/MIME BR.
As it is clear there were varying perspectives on the requirement, given the historical widespread use of emailProtection for document signing use cases, ideally this emphasis would be clearly laid out in the updated Apple policy, with a forward compliance date.

[ChyaHungTsai]

We would like to confirm our understanding: If we have a Subordinate CA whose Trust Purpose is 'Legacy TLS', the Subordinate CA certificate MUST contain both serverAuth and clientAuth EKUs. However, the Subscriber certificates issued by this CA may contain only serverAuth, only clientAuth, or both. This feels a bit strange / inconsistent.