Hi Ryan,
We consider the CP/CPS content primarily when the WebTrust Criterion
specifically mentions those documents, which is mainly in Principle 1, or where
they serve as a reference, e.g., when testing issued certificates to verify
that they contain the correct OIDs, etc.
For the majority of the WebTrust criteria, we review the internal policies and
procedure documents, interview responsible people, observe processes, examine
configurations, etc., most of which is at a detailed level not appropriate for
a document published on a public website, but enables us to determine what they
actually did, and whether it meets the criteria. Checking to see whether what
they actually did is consistent with what they disclosed in the CP/CPS
document(s) in effect during the audit period is part of testing Principle 1
criterion 1. (Principle 1 criterion 4 only requires annual updates to the
CP/CPS as well.)
Put another way, the CP/CPS *describe* how the CA implements the Requirements.
They don’t *govern* how the CA operates.
A WTBR audit provides an opinion on whether the CA operator has:
* Disclosed its TLS certificate lifecycle management business practices in
its [list of CP and/or CPS documents that were in effect], including its
commitment to provide TLS certificates in conformity with the CA/Browser Forum
Requirements on their website, and provided such services in accordance with
its disclosed practices;
* Maintained effective controls to provide reasonable assurance that:
* The integrity of keys and TLS certificates it manages is established
and protected throughout their lifecycles; and
* TLS subscriber information is properly authenticated (for the
registration activities performed by the CA operator; and
* Maintained effective controls to provide reasonable assurance that:
* Logical & physical access to CA systems and data is restricted to
authorized individuals;
* The continuity of key and certificate management operations is
maintained; and
* CA systems development, maintenance, and operations are properly
authorized and performed to main CA systems integrity.
Throughout the period [date to date], based on the WebTrust Principles and
Criteria for Certification Authorities – TLS Baseline vx.x
There are other forms of PKI audits that we perform that do not have a defined
audit framework like WebTrust to audit against, and when auditing those, the CP
and CPS are central. Typically, the body that the report goes to has a CP of
its own that the entity being audited needs to conform their CP to. Then,
their CPS contains procedures that govern how they implement the CP. The audit
consists of examining the CP and confirming that it conforms with the report
requesting body’s CP. Then we examine the CPS for conformance to the client’s
CP, and then we evaluate the client’s operations for conformance to their CPS.
Those types of audits result in the client providing a Management Assertion
that contains statements like:
“With respect to our compliance with certain requirements in the associated CP
and CPS documents that were in effect during the compliance period, [Client]
asserts the following:
1. Procedures defined in Section 1, subsections 1.5 of the CPS have been in
place and operational.
2. Procedures defined in Section 2, subsections 2.3 and 2.3 of the CPS have
been in place and operational.”
Etc.
Hope this is helpful.
Jim
p.s. The above are my own thoughts and opinions and do not necessarily
represent those of my employer or anyone else.
Jim Scardelis
M.S., CISSP, CISA, CEH, CCSK, QSA, PCI Secure Software, Secure SLC, P2PE, &
P2PE Application Assessor, PCIP, CIPP/US, CIPP/C, CIPP/E, CIPT, CTT+
Technical Lead - Crypto/Digital Trust
1.866.254.0000 ext. 584
SOC • PCI • HITRUST • FedRAMP • ISO
[https://res.cdn.office.net/assets/bookwithme/misc/CalendarPerson20px.png]<https://outlook.office.com/bookwithme/user/[email protected]?anonymous&ep=signature>
Book time to meet with
me<https://outlook.office.com/bookwithme/user/[email protected]?anonymous&ep=signature>
Upcoming Out of Office dates:
March 1-8
March 19-20
April 2-3
March 19-20
April 2-3
From: Ryan Hurst <[email protected]>
Sent: Wednesday, February 18, 2026 15:03
To: Jim Scardelis <[email protected]>
Cc: Ryan Hurst <[email protected]>; Trevoli Ponds-White
<[email protected]>; CCADB Public <[email protected]>
Subject: Re: CP/CPS Content Consistency Proposal
Jim,
I may not have been clear in my original ask, so let me restate it. I wasn’t
suggesting audits are “based on the CPS.” I understand WTBR is the audit
criteria and it maps to specific BR versions. My question was about the bridge
step: when you move from a WTBR criterion to evaluating what a CA actually
does, what role does CP/CPS specificity play?
Your walkthrough answers that directly. You described the workflow as WTBR
criterion > mapped BR section/version > CP/CPS > evidence/testing. That makes
the CP/CPS the document auditors use to connect the criterion to the CA’s
implementation choices and the evidence trail, which is exactly why the
specificity question matters.
This is also where I think Trev’s Proposal 1 runs into a structural problem. If
the CP/CPS is primarily incorporation-by-reference (“we comply with the BRs”),
then in the bridging step you described the auditor is sent back to the same BR
text they already have open rather than to CA-specific, testable commitments.
Two points you raised make that especially problematic.
First, version lag. You noted WTBR criteria often map to older BR versions. A
CP/CPS that mostly points to “the BRs” without describing the CA’s actual
current operational practice and parameters makes that translation harder, not
easier.
Second, multi-framework use. You noted the same CP/CPS is used across multiple
audit frameworks. If it is too thin to describe a CA’s actual practices in
auditable terms, it fails multiple audiences at once.
This is not abstract. Bug 2009525 is a concrete example. Language like “may be
backdated by a few hours” without a bound or threshold is not something an
auditor can evaluate as a measurable commitment under the bridge process you
described. And it does not meet what Apple, Mozilla, and Chrome have now said
explicitly they expect from a CP/CPS.
So your process description ends up supporting the opposite conclusion from
Proposal 1: if the CP/CPS is the bridge from WTBR criteria to actual practice,
it needs enough specificity to describe the CA’s implementation choices in a
way that can be mapped to evidence and tested.
Ryan
On Wed, Feb 18, 2026 at 4:25 AM 'Jim Scardelis' via CCADB Public
<[email protected]<mailto:[email protected]>> wrote:
Since Ryan asked for auditors’ input .….
As a WebTrust practitioner, the most current CA/B Forum Baseline Requirements
are not what we audit against. Neither is the CPS. In my personal opinion (and
only my opinion, not that of my employer or anyone else), both proposals would
make it much more difficult to conduct the various audits that CAs subject to
the CA/B Forum BRs have to go through (see the WebTrust Engagement
Applicability
Matrix<https://www.cpacanada.ca/-/media/site/operational/ms-member-services/docs/webtrust/engagement-applicability-matrix_final_aoda-compliant.pdf?rev=d0091ed381f74635ba2736c16978ec78&hash=1FD5E0964D6C3E689353DEAE5A21E2B2>
for details on those, but it’s at least three, all of which use the same CPS.)
More details on my reasoning below, but the [tl;dr] is IMHO, the current
language is already optimized, and keeps the CPS readable.
For the purposes of this discussion, we would be auditing against the WebTrust
Principles and Criteria for Certification Authorities – TLS
Baseline<https://www.cpacanada.ca/-/media/site/operational/ep-education-pld/docs/01618-ms-24-3852_webtrust---tls-baseline-v29.pdf?rev=e0678ebc91614665b1b2d0a25a50d9bf&hash=5837E2C482F5162302AA0A61A1EE6B38>
framework (“WTBR”) . WebTrust frameworks aren’t updated as often as the CA/B
Forum updates their requirements, and there is typically a delay in time before
we have to use a new version - that is determined by the starting date of the
engagement period.
So, for example, a client undergoing their annual WTBR audit that had their
previous audit period end on January 31, 2025, would now be audited for the
period from February 1, 2025 to January 31, 2026 – against WebTrust Principles
and Criteria for Certification Authorities – SSL Baseline Requirements v2.8,
since the version linked above (v2.9) is required for engagement periods
commencing on or after April 1, 2025.
This matters because the each of the WTBR standards is based on a particular
version of the CA/B Forum Baseline Requirements:
* WTBR v2.8 is based on CA/B Forum Baseline Requirements version 2.0.1
* WTBR v2.9 is based on CA/B Forum Baseline Requirements version 2.1.2
* WTBR v2.10, which is for engagement periods commencing on or after
December 1, 2025, is based on CA/B Forum Baseline Requirements version 2.1.7
When conducting the audit, we consider the CA’s compliance with each of the
applicable WebTrust criteria. For WTBR, most of the criteria include references
to one or more specific sections of the CA/B Forum BRs. As stated in the WTBR
standards, “The practitioner is directed to consider the referenced Section(s)
as part of assessing the CA’s compliance with each criterion.” The referenced
section(s) mentioned refer to section in the version of the CA/B Forum BRs that
the WebTrust standard was based on, *not the version that CAs are currently
required to conform to*.
Additionally, for a CA that would be subject to the CA/B Forum TLS BRs, the
WTBR audit is one of at least three that we will be auditing them against using
the same CPS document – WebTrust for CAs (required for all of types of CAs),
WTBR and WebTrust for CAs – Network Security. The CPS is where their
practices, policies and procedures that are applicable to all of them are
disclosed, and each of the WebTrust standards has requirements around the CP
and CPS.
As a result, each section of a CA’s CPS is topical and not necessarily directly
related to the CA/B Forum BRs. Every CA I’ve audited includes a reference to
conformance with the latest version of the Baseline Requirements .… issued by
the CA/Browser Forum because WTBR Principle 1, Criterion 1 includes
“The CA discloses on its website .… its commitment to conform to the latest
version of the Baseline Requirements .… issued by the CA/Browser Forum.” This
criterion in each of the above versions, for example, also references section
2.2 and 3.2.6 of the CA/B Forum BRs, so in deciding if a client being audited
under WTBR v2.8 is compliant with this criterion, I would look at their CPS to
see if it is posted on their website; are cross-certificates disclosed; and is
there a statement either on their website that discloses their commitment to
conform to the latest version of the BRs. And then, I would open up the CA/B
Form BRs version 2.0.1, look at sections 2.2 and 3.2.6 and consider whether
they had met those as well.
The only time that I would consider more recent versions of the CA/B Forum BRs
would be if the CAs practices differed from what the referenced sections said
in a way that was less strict. In that case, I can look at the more current
versions of the BRs in effect during the audit period say, and for that one
criterion, consider if their practice was because of the changed requirement.
Finally, WebTrust for Certification Authorities v. 2.2.2, which covers topics
like the process for verifying various elements that are provided by an
applicant for a certificate, groups criteria differently than the CA/B Forum
BRs. For example, in WebTrust for CAs, there is one criterion and illustrative
control that covers all types of authenticated certificates, while the CA/B
Forum BRs spread them out by type, with repeated requirements for parts of each
type.
All of which means that including the text of CA/B Forum BRs throughout the CPS
would actually make auditors’ jobs much more difficult.
Jim
Jim Scardelis
M.S., CISSP, CISA, CEH, CCSK, QSA, PCI Secure Software, Secure SLC, P2PE, &
P2PE Application Assessor, PCIP, CIPP/US, CIPP/C, CIPP/E, CIPT, CTT+
Technical Lead - Crypto/Digital Trust
1.866.254.0000 ext. 584
SOC • PCI • HITRUST • FedRAMP • ISO
[https://res.cdn.office.net/assets/bookwithme/misc/CalendarPerson20px.png]<https://outlook.office.com/bookwithme/user/[email protected]?anonymous&ep=signature>
Book time to meet with
me<https://outlook.office.com/bookwithme/user/[email protected]?anonymous&ep=signature>
Upcoming Out of Office dates:
March 1-8
March 19-20
April 2-3
March 19-20
April 2-3
From: [email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>> On Behalf Of Ryan Hurst
Sent: Friday, February 13, 2026 15:23
To: Trevoli Ponds-White <[email protected]<mailto:[email protected]>>
Cc: CCADB Public <[email protected]<mailto:[email protected]>>
Subject: Re: CP/CPS Content Consistency Proposal
Thanks Trev, I appreciate you engaging directly on this.
I agree that duplicating required BR text often doesn't add clarity and just
creates maintenance headaches. Your example around reasons 6-16 is a good one.
That's the kind of discretionary parameter that belongs in the CPS, in my
opinion. Same logic applies to validation methods and profile constraints where
the obligation is mandatory but operational choices vary. Same with EKU. The
option space has narrowed, but the CA should still state which values appear in
which profiles.
Where I think there's more to work through is what belongs in a CPS when a CA
incorporates by reference. If "only describe optional or discretionary items"
becomes the principle, we lose something. A requirement can be mandatory in the
BRs while the way a CA implements it still involves choices that affect risk
posture. The distinction is less "required versus optional" and more "normative
obligation versus implementation choice." Incorporation by reference
establishes the obligation. It doesn't always make the CA's posture visible.
One concern with the "SHOULD NOT include details about required practices"
framing. It could discourage CAs who want to be more transparent. We should be
careful not to create a norm that penalizes specificity. Taken to its
conclusion, that rewards minimal disclosure. CAs that say less create less
surface area for findings.
This also has audit implications. Auditors audit against the CPS. If the CPS
just says "we comply with the BRs," what is the auditor actually testing
against? The CPS says we comply, the auditor confirms we said we comply.
Without implementation specifics in the document, there's less to measure. Over
the last several years we've seen more CAs default to "we comply with RFC 5280"
without specifying profiles. In my experience, few auditors in this space have
the technical depth to independently identify which implementation details to
drill into. The CPS is their roadmap. If it's vague, the audit will be too.
On validation methods, the CPS doesn't need to restate what each BR method is.
But it should state which methods the CA uses, which it doesn't, and any
constraints on how they're implemented. That's not duplicating the BRs. It's
disclosing choices.
We saw why this matters with the TLS-ALPN-01 flaws in early 2022. When
vulnerabilities turned up in a CA's implementation of 3.2.2.4.20, the ecosystem
needed to quickly assess who else was exposed. That triage only works when CAs
enumerate what they use. If every CPS just says "we use approved methods," root
programs have no starting point and the response turns into a polling exercise.
Bug 1962829 is worth looking at too. Microsoft's CPS had a specific commitment
about keyEncipherment in RSA subscriber certs. Turned out to be a typo that
didn't match practice. A third-party researcher caught it. It was just a typo,
and not a consequential one but it was only catchable because the commitment
was specific and measurable. If we remove specificity what happens when the
error actually matters?
The alternative to a detectable error is an undetectable one, even if minor. If
a CA can't detect its own implementation errors, removing that information from
the CPS means no one else can either. That raises a fair question about what
else might be going unnoticed.
On your threshold question, if someone has to leave the CPS and interpret
external documents to understand what the CA actually does, the document isn't
doing its job. That doesn't mean restating every clause. It means the CA's
choices, bounds, and constraints should be findable in one place.
I wrote up some broader thoughts on this at
https://us01.z.antigena.com/l/FG0A7qEmnyPiHyI0eCOu8gQjvFUTAT4M4ubAcFCh-muvY0hB-kkaWfJcwKMMLLaFeoWZULx_LW3ZzkuznRdow8KxmeMJHNSt-QRWMPCErCOnXFi3LXIvkY5QMtggHUrvYmBnpYx-UfK7l5T7uaeAgXIz6pXR92hiI0uJ0m087UxE5PSMacZ34Wzm-8rVJV6oyy
for anyone interested in the longer version.
Ryan Hurst
On Fri, Feb 13, 2026 at 2:20 PM 'Trevoli Ponds-White' via CCADB Public
<[email protected]<mailto:[email protected]>> wrote:
Thanks Ryan, you are definitely a good voice to weigh in on this topic. Looking
at some of your examples I think they are definitely a mix of what I would
consider BR copy pasta vs unique information. For example I think the 24 hour
revocation SLA for reasons 1-5 is very clear and not optional. I’m not sure
what it adds for all CAs to repeat this? Alternatively for reasons 6-16 it’s
more interesting because there is an optional time frame there. Under my first
proposal I would expect a CP/CPS to state the timeline a CA tries to use.
Extended Key Usage is another good example where we have evolved the BRs to a
place where there are less options than there used to be. Rather than CAs
listing items that are not allowed or strictly required a section like this one
“7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage – Restricted” has
more value if it specifically addresses if “Any other value” is present and why.
I think you also bring up something that I think is fundamental to resolve.
What is the threshold we think is fine for parties to have to reference the
various baseline requirements to understand what a CA is doing? I think this is
core to the discussion. The BRs allow incorporation by reference because of
this it’s a very common practice. Section 3 is a good example of this. Most CAs
do not describe the validation methods. Do we think that CAs should add the
descriptions into their docs so that consumers don’t have to look at the BRs to
understand them?
On Friday, February 13, 2026 at 1:42:40 PM UTC-8 Ryan Hurst wrote:
Thanks, Trev. I care a lot about this topic and think it’s an important
discussion for the ecosystem.
I put some thoughts on the bug
(https://us01.z.antigena.com/l/FPW1RbEmpif0KE8eTNvI9ou9J5_-B9fKsAM4bxiDdqUCU4kqT7eXWXH-I_wj4J0-ppm72j0D_86-ay0VwYsrHhOSvDMkFL-Orauu_rMQ4aTIKpxxodw82x2VTB2l8qKX_XFpD7EPXjyKCacm8PDCe8XukRqnQcKMYFAVmLzuIJAXq8xD0DjQG4K-BfBWuq0NjidrXA5AYLj9im
) that frame how I’m thinking about CP/CPS structure and governance. I
initially tried to reply here but realized I had to request access, so the bug
seemed like the easiest place to respond in the moment.
Happy to discuss any of those points here and hear other perspectives.
I’d be especially curious to hear from auditors about how they are evaluating
these documents in practice. How much specificity do they rely on in the CP/CPS
itself versus interpreting incorporation by reference? That seems like a
critical input to getting this right.
Looking forward to the discussion.
Ryan Hurst
On Friday, February 13, 2026 at 11:53:40 AM UTC-8 Trevoli Ponds-White wrote:
Hello!
We want to start a conversation about bringing more clarity and consistency to
expectations for CP/CPS content. We posted this here so that non-CA/B F members
can provide feedback and because we can think of several ways to do it. An
update to the Baseline Requirements, CCADB policy update, or an update to one
of the Root programs’ policies.
This isn’t the first incident about CP/CPS content the community has had but
it’s a good place to start with for background
https://us01.z.antigena.com/l/FPW1RbEmpif0KE8eTNvI9ou9J5_-B9fKsAM4bxiDdqUCU4kqT7eXWXH-I_wj4J0-ppm72j0D_86-ay0VwYsrHhOSvDMkFL-Orauu_rMQ4aTIKpxxodw82x2VTB2l8qKX_XFpD7EPXjyKCacm8PDCe8XukRqnQcKMYFAVmLzuIJAXq8xD0DjQG4K-BfBWuq0NjidrXA5AYLj9im
.
We have two proposals to start the discussion. If people have other proposals
or feedback about these, please share them.
Proposal 1 – Update Section 2.2 of the Baseline Requirements
Change the existing language:
The CA SHALL publicly give effect to these Requirements and represent that it
will adhere to the latest published version. The CA MAY fulfill this
requirement by incorporating these Requirements directly into its Certificate
Policy and/or Certification Practice Statements or by incorporating them by
reference using a clause such as the following (which MUST include a link to
the official version of these Requirements): [Name of CA] conforms to the
current version of the Baseline Requirements for the Issuance and Management of
Publicly-Trusted TLS Server Certificates published at
https://www.cabforum.org<https://www.cabforum.org/>. In the event of any
inconsistency between this document and those Requirements, those Requirements
take precedence over this document.
To something like:
The CA MUST publicly give effect to these Requirements and represent that it
will adhere to the latest published version. The CA MAY fulfill this
requirement by incorporating these Requirements by reference into its
Certificate Policy and/or Certification Practice Statements. If the CA does
this the reference must be in Section 1.1 and MUST list which documents it is
referencing by title and must include the link to the document’s landing page
i.e. “Baseline Requirements for the Issuance and Management of Publicly‐Trusted
TLS Server Certificates
https://us01.z.antigena.com/l/FUQCybnjgy1X-0YVScoqasPJWJb3V-3CD7gOvK~BOBXSh2DXJMt6mfskHLIqXZaSFWzQIbRhQ0blOTJQ4fCCBEZeKGXw5TqelWhsY-Zana54sbV8GIGgypqe6-xnKvrUcPT77fqVPaBf7ZJAQm1vjs2ZTv_XDacJHQKH9Etk06MQ1yEixr9Pg85Di6-flh3huEGc7j
r/baseline-requirements/<https://us01.z.antigena.com/l/joTNwbdm8ssK0CdpqZ0SMk6k3~M8sVmUpXNQ1S9GtMMSSFSzY2WkW2-giA0OjhEakgb-OInefTmeD5jn2bMSvsgp2ll13M2d4J~le91BIUauyIasXFjz9eaeraRmUhr4n9F7vwdxWkojt3HrTY4-wXN~gwdcdjgCQr5ZwCEOCzs2Eofmn5FbRO2yQLvLhKHfQl4FoLMr9~i~MMT5Ri4HAE~Ydggl>”.
The CA MAY also include the following in Section 1.1: “In the event of any
inconsistency between this document and those Requirements, those Requirements
take precedence over this document.” CAs that incorporate requirements by
reference SHOULD NOT include details about required practices. CAs that
incorporate requirements by reference MUST include details in places where the
referenced documents express optional requirements i.e. “No stipulation,
SHOULD, SHOULD NOT, MAY, optional.
In practice this would result in, for example, Section 4.2.1 (for TLS certs)
CAs would have to describe if they reuse validation data but not required items
such as: “Applicant information MUST include, but not be limited to, at least
one Fully-Qualified Domain Name”.
Proposal 2 – Adopt a style similar to Matter PKI by the Connectivity Standards
Alliance (CSA)
When CA's submit a CPS to the CSA it is laid out where the requirement is
stated. Following that there is a spot for the CA response when required.
Example:
4.2 - Certificate Application Processing
It is the responsibility of the CA/RA to verify that the information in a
Certificate Application is accurate.
CA Response: <insert response>
CA Response:
Before issuing Matter Certificates, the CA verifies Vendor identity &
information through the following process: 1) Vendor requests a Distributed
Compliance Ledger (DCL) challenge to prove ownership of their DCL private key;
2) The CA verifies the DCL challenge; 3) The CA retrieves Requester data for
the RAD and Certificate Application; 4) The CA verifies the Vendor's
information against a known database; 5) The CA generates the RAD and
Certificate Application with the verified data; 6) Vendor signs the RAD and
Certificate Application; and 7) The CA creates the Vendor for PAI issuance.
Given that we have been moving the CA/B F requirements in a direction where we
have greater specificity and less leeway we think this is a good time to
revisit more specific requirements for CP/CPS content as well.
Thanks!
Trevoli Ponds-White
Amazon Trust Services
--
You received this message because you are subscribed to the Google Groups
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected]<mailto:[email protected]>.
To view this discussion visit
https://us01.z.antigena.com/l/DSx1PkghwwODeZZfljhkaKXMonK8vcIUp0GqfOBa0qYD4ME9ohSHFonX-JckjlyGkL76iWb5L7uWcESG3W3hWu-aETvv58sdrRph7uiBJgxmPmMqgno-~q41KZnEMg53BkiQaEd5~V-ZZXM8T8weGCvL3kC_vArvG0I88i4sVr3eMckWUmT1LSeV2_xo~-XDzwKoDZV3gQm9Bl~OIOQhxJG4jGvLDqF1Foh-RHyXmFYDnXi5_ktadilI
<https://us01.z.antigena.com/l/ap6gj6MYAL9ZwMm7VQXYIiczsem83EiayYGM_lXnwZoKBCLUj6mBURx~cUxZfKzXxzDgTnXxNvPNkN77m1G4MThi6djhkyQGsHRjfT_lIbzmkfWhCA9KptlMDxGsF_GNMOkljqags3G8l4GW1IFEJ2_FGl~yt0MhbTtD2w8h0tUWKef0sQHSHij-6gMh1_QCEE2NnLY_H_kqfPNehLox-trfadsEl1T-ArWZMFzPppve~9PEPyMW-Ez~21Do1wRWejVjoFSvV4W4sqUyl2~VoBL>
.
--
You received this message because you are subscribed to the Google Groups
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected]<mailto:[email protected]>.
To view this discussion visit google.com
<https://us01.z.antigena.com/l/5i2KwrDeqf4mM4WJlKcAXLqqKhDIhTPCciAnwbkYQ4TlJI8H6j2Z-0srSrGldCM7Gf1~3ojJVLS7gIH4uZT2GvSSlFJOi~UaBXSZFEanElXOMM90WWtvN2catkB2llVS~vKb~zflMK~Ft~10hfzvnILtrtqIjtAKzJ07JZGSnOM4xn97Hl6vxTpBRhiJB1hm6q~RZ1x4oCXb7snkySoKO6YJb6klIOATUOwfavBy8KK-QdiWObwux67f3wJWUHnb36alufZcwbE3136asPfFOwbl8CoBFI8gTpUXowmPo2Aid~Qy5x8mrgTNe-RivCtWRe>
.
--
You received this message because you are subscribed to the Google Groups
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected]<mailto:[email protected]>.
To view this discussion visit
https://us01.z.antigena.com/l/WMmkiE7BbsJIxGbmma8OxIyF_4yjeREI7YfFiO5fBA184t0evXflKifJ~39JO4QnibwqVP7tmsGUwEp6FNg56kAQCz2p9bF9DlSKVM2wp8xy6ob9G3NjdYhIRF99snY1SIeES4KnRdHqjDk~_CclvTKIJdjknSaI~m9GZwtT3nYhMyTh45HKKPPzGMCP6wiKQCXicYVoY3WfPLj7Wvk4a0NLZJs1WsvO-ZBO5kCrO131UFjDe2LdDWU2v6Fwy~ILOZ_X3IHpyUe1xOQIowmRZ--
<https://us01.z.antigena.com/l/Zn3xClJcjveIvZEc4pw80dGO0R2DE-r7naNtaMJLnE1~MaR8PGICC5ICKVYO01gM59sdYNh25u7a-YOw8xxg2DleAwsypMo4i3auwmzuW9r10RMtMNeaauYvtIfZUq92YFtt~qD4LL~pL2mFrD6pGyYgmWuNLeJiJbs5eFX8tZ~0~xEbK4lf~u2Km-lPEnkzr2J5VN1bG4qGtWdaadpkzCQXFhQWBBdgkRPmDlVFd9ndGNX5dlhDazeX4Cr49KdvIsArdDjCHuOPpHQpuAqLLgLJj3LM3oVW--E092s61MzJ3tu-poLzvv4x>
.
--
You received this message because you are subscribed to the Google Groups
"CCADB Public" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/a/ccadb.org/d/msgid/public/CH3PR14MB67700B284F6A35694A675B4FFE6BA%40CH3PR14MB6770.namprd14.prod.outlook.com.
