Hi Martijn, et al.,
The CCADB Steering Committee had the opportunity to review and discuss
the constructive feedback provided in this thread (thanks for that!).
As previously hinted, we were planning to make some changes to policy
document handling in the CCADB as a larger enhancement request, and
this is an opportunity to collect some feedback.
Currently, new policy documents are always added as new records in the
CCADB. References get added (A) to Root Certificate record(s) via an
‘Add/Update Root Request’ Case after a Root Store Operator syncs the
information from the Case with the root record(s) (as they do today),
or (B) directly on Intermediate Certificate records by CA Owners (as
they are today).
Here is how we think publishing new policy documents (e.g., CP, CPS,
or CP/CPS) could be handled in the CCADB going forward:
1.
When a new policy document is added and associated with a Root
Certificate record, if a previous version of that document exists
(i.e., an earlier version of the policy document being added), we
will expect that the previous version of that document would then
be “superseded”. “Superseded” intends to avoid potential confusion
from the existing term “Delete” and other suggested terms (i.e.,
“Archived”, “Obsolete”, “Withdrawn”, etc.), since previous policy
documents can still be applicable in the ecosystem. Further:
*
All policy document records would be updated in the CCADB to
include a new field: Policy Document Superseded Date.
*
During the “Add/Update Root Request” Case process, when adding a
new policy document and associating it with applicable Root
Certificate records, the CA Owner can select any existing policy
document and click a new Supersedebutton to edit that document
record and to specify the date it was superseded.
o
When editing an existing policy document that has already been
synced with Root Certificate record(s), only the Policy
Document Superseded Date field can be edited.
o
All fields for new policy documents that are being added to
the Case can be edited until the Case is submitted for Root
Store Operator review (as they are today).
*
During the deployment of this enhancement and for previously
“Deleted” policy document records, we can set the Policy Document
Superseded Date field to the Last Modified Date. CA Owners will
have the ability to edit this date as needed on the policy
document record.
*
In the CCADB, the reference to a superseded policy document will
behave the same as those that are “Deleted” today, with the
various options that allow a user to hide or reveal superseded
documents.
*
In an ‘Add/Update Root Request’ Case, a warning will be presented
for existing policy documents that have not been superseded after
335 days. The warning will progress to an error at 365 days,
aligned with the annual update requirement of Section 2 in the
CA/Browser Forum’s TLS, S/MIME, and Code Signing Baseline
Requirements.
*
In the CCADB, all references to policy documents on Root
Certificate records will have a File Archive Association (as they
do today).
2.
CA Owners can directly add and modify references to policy
documents on their Intermediate Certificate recordsor identify the
policy documents to be the same as the parent record (as they do
today). Further:
*
On the Intermediate Certificate record, we will add the ability to
identify if the CP, CPS, or CP/CPS is the same as the parent
record, rather than only having the ability to identify “CP/CPS
same as parent”, which is today’s current state in the CCADB.
*
When an Intermediate Certificate record is modified with policy
document information and saved, that policy document will
automatically be archived and identified as superseded. The Policy
Document Superseded Date field will be populated on the archive
record with the date the Intermediate Certificate record was
modified and saved.
*
On the Intermediate Certificate record, a warning will be
presented for existing policy documents that have not been
superseded after 335 days. A new warning will be presented at 365
days, aligned with the annual update requirement of Section 2 in
the CA/Browser Forum’s TLS, S/MIME, and Code Signing Baseline
Requirements.
These proposed changes have simplicity in mind, while also:
1.
allowing the CCADB to have similar logic of showing only the
latest version of policy document(s) in default views;
2.
providing more explicit “closure” for when a document has been
superseded by another; and
3.
avoiding confusion about a policy document having different states
beyond effective and superseded.
Again, we appreciate the feedback on this thread and value the
community's perspective on this proposal.
Thank you
-Chris, on behalf of the CCADB Steering Committee
On Tue, Aug 20, 2024 at 3:30 AM 'Martijn Katerbarg' via CCADB Public
<[email protected]> wrote:
>I also disagree with the complexity introduced by Martijn's
suggestions. IMO simplicity should drive any rules around this issue.
My tentative suggestions for tweaking the policy language are
rather aimed at making things simpler by ensuring that each party
is following the same practices, which is something that is
currently not occurring. Fully agreed that simplicity is the way
to go with this. Trying to establish with the root program owners
what the current rules actually are, would be a first step forward
in that process.
Op maandag 19 augustus 2024 om 19:50:59 UTC+2 schreef Dimitris
Zacharopoulos (HARICA):
On 19/8/2024 6:23 μ.μ., 'Aaron Gable' via CCADB Public wrote:
I agree that older versions of CP/CPS documents are important
and useful, and ideally should be exposed for parties who
want to see versions that were in effect when older
certificates were validated or issued.
But the reality is that, for example, Let's Encrypt's CCADB
pages were nearly unreadable due to the huge listing of
historical CP/CPS documents. It was also incredibly difficult
to tell which documents were relevant because we had made a
change from separate CP and CPS to a combined CP/CPS. The UI
simply displays all historical documents, with no ability to
filter by when they were in force, and no ability to easily
see which newer document replaced them. So we decided to go
through and mark all historical versions of our documents as
"deleted" to make the pages readable and usable again.
Ideally, there would be a nice in-between. But today, keeping
many historical document versions active results in an
unfortunate user experience.
Would it make sense for CCADB to automatically mark a previous
version as "superseded" when a new version is uploaded?
Dimitris.
Aaron
On Mon, Aug 19, 2024, 08:11 'Dimitris Zacharopoulos (HARICA)'
via CCADB Public <[email protected]> wrote:
Apologies for top-posting.
It's a bit unclear to me "why" this distinction (of a
CP/CPS being declared as "deleted" or not in CCADB) is
important. IMO this is a source of confusion and may lead
to many different interpretations of the expectations.
A CP/CPS has an effective date, just like the BRs. When a
new version of a CP/CPS is released, it has a new
effective date. This doesn't mean the previous CP/CPS
documents are not useful for a public PKI (either for TLS
or Code Signing, S/MIME, etc), or that it should be
marked as "deleted" or "obsolete".
As an example why old versions are useful, when a CA
performs a Domain Validation, this is performed at time X
and could be re-used for X+398 days. This means that a
certificate for the same Domain Name could be issued with
a CP/CPS of version X, and a re-newed certificate could
be issued under a newer CP/CPS but it would include a
Domain Validation that was performed under the rules of a
previous CP/CPS (at time X).
CCADB should try to keep things as simple as possible.
When a new version of a CP, CPS, or a CP/CPS is uploaded,
it should just add it to the "Repository" of documents
associated with a certain CA. Relying Parties should know
how to process and read these documents and how to
process their effective dates. I don't think there is a
need to flag a document "deleted" or "obsolete" because
there are important elements in each CP/CPS version. As
Ben highlighted, CAs are already required to publish all
the versions of their CP/CPS documents on their public
website. It would only make sense to flag a document in
CCADB as "withdrawn" (or similar) to indicate that the
information of that document is incorrect, or uploaded by
mistake.
I also disagree with the complexity introduced by
Martijn's suggestions. IMO simplicity should drive any
rules around this issue.
Best regards,
Dimitris.
On 19/8/2024 5:00 μ.μ., 'Martijn Katerbarg' via CCADB
Public wrote:
Thank you all for the feedback so far. Firstly, I wanted
to clarify that we’re aware that none of the data is
ever really removed from CCADB. The mentions of deleting
items in my original post referred to the CCADB option
to mark them as deleted.
In response to Clint:
>I think it’s worth noting that 1 & 3 are, I believe,
mostly the same; that is, Policy Documents marked as
“Deleted” in the CCADB are not removed from the database.
The difference between these options that I was
attempting to convey is that, in option 1, “old” CPSes
are marked as deleted; whereas in option 3, they are
not. With that clarification, we take note that Apple
sees option 1 as the preferred option at this moment.
Since Chris has expressed the same preference on behalf
of the Chrome root program, would it be appropriate to
declare that option 1 is the requirement?
>Regarding the “change log” sections of Policy
Documents, I agree there’s not much specific guidance on
what is desired or expected here. Both a summary of the
changes and a list of sections in which changes occurred
seem particularly valuable to me; are there any other
suggestions or ideas from the community on this?
I think the recent changes in the Chrome Root Program
Policy are a good step forward in resolving this.
Specifically:
“/To promote simplicity and clarity, these CA policy
documents SHOULD be:
…..
/
/available in Markdown./”
I presume this was added partially to aid in comparing
different versions.
In response to Ben:
>I think the middle option is the best choice, and the
first bulleted item is a second-best choice, although
any of them are appropriate.
It seems Mozilla has a different preferred approach
(Option #2), but does not set a hard requirement on this.
In response to Mike:
> I think the most common practice is 1, though?
Both options 1 and 2 seem to be common at present.
> = is accompanied by a CPSHash property in the cert
The CPSURI is not a required field for end-entity
certificates, so I’m not sure any new CPSHash property
would be a required field in the future.
> a CPS is marked “obsolete” or “expired” or whatever
the definitions WG comes up with once there are no valid
certs left that reference the CPS in question
While such an approach *might* work for the TLS WebPKI
(though I’m not a fan of the approach), it might cause
issues when looking at S/MIME and Code Signing, in which
certificates are still useful after expiration.
Different policies for TLS compared to other
certificates seems like it would open the door to
incorrect executions down the line. A unified approach
here would be strongly preferred.
As some final thoughts to all:
It remains unclear if any of the root programs would
categorise any of the 3 options as either MUST or MUST
NOT. Currently, I’d summarise it as preferred
approaches. Since the preferred approaches also do not
fully align, would the CCADB Steering Committee be
willing to discuss a singular, unified approach, and
clarify the requirement in a future CCADB policy update?
Document archival for “deleted” CP/CPSes is only
available for Root Certificates in CCADB, as far as we
can tell. Many Intermediate Certificate records have
“Same as Parent” set, but that is not the case for all.
If “Same as Parent” is not set, the applicable CP/CPSes
are entered via freeform text fields in the Intermediate
Certificate record. As such, we currently understand
that these fields should always have only the last
published version listed (within 7 days after publication).
Regards,
Martijn
Op zaterdag 17 augustus 2024 om 11:03:02 UTC+2 schreef
Mike Shaver:
On Fri, Aug 16, 2024 at 7:15 PM Chris Clements
<[email protected]> wrote:
(e.g., the in-force CP for a given PKI hierarchy
is incremented from Version 1.1 to Version 1.2),
it should be replaced with data that is accurate.
1. The new CPS should be added, and the old
CPS should be deleted as it is no longer
in effect for new certificate issuance.
2. The new CPS should be added, but the old
CPS should be kept in place as long as
there are unexpired certificates under
its policy.
3. The new CPS should be added. Older
entries should be kept indefinitely to
serve as an archive overview.
The Chrome Root Program prefers CA Owners behave
similar to #1, but as described above, “delete”
is not the most appropriate term for the
non-current versions of the policy documents. In
actuality, the system behavior is more
consistent with #3 due to document archive
functionality.
OK, I may be confused here and talking nonsense, but
I don’t think that there is necessarily (or even
likely) a single in-force CP for a given PKI
hierarchy at a given time. A policy is bound to a
cert via the CPSUri when that cert is issued, and
the policy relating to that cert is then immutably
fixed. That’s why we’ve seen revocations necessary
for certs issued in ways that didn’t match the
contents of CPSUri at the time that the cert was
issued, since the only way to remedy that is to
issue an new cert bound to the updated policy.
At the moment that a new CPS comes into effect, it
actually relates to _none_ of the live certs in the
hierarchy, and depending on the update schedule for
the CPS, it might not at any point even apply to a
plurality of such live certs. CCADB should at least
have all the CPS documents that apply to any live
certs under a registered root, IMO, and they should
all be treated as equally “active”.
Unfortunately, this weak binding (requires that a
human go to a URL and pick the one that applies to
the date range and cert type) sort of sucks in terms
of clarity and garbage collection.
If I were designing this system now, I would
probably make the rules be:
- CPS documents are markdown-enhanced text files
- each CPS gets a unique URL, ideally with a
human-readable/collatable version number as a component
= either a content-addressable hash-carrying URL
hierarchy hosted under ccadb.org <http://ccadb.org>, or
= is accompanied by a CPSHash property in the cert
- a CPS is marked “obsolete” or “expired” or
whatever the definitions WG comes up with once there
are no valid certs left that reference the CPS in
question
That would let the matching of applicable CPS to
cert be mechanically performable, rather than the
gross version-walking-in-an-HTML-index that has to
happen now. Making it be markdown would mean fewer
changes that are due to formatting, and improve the
ease of mechanical analysis.
I’m squinting through some meaty jet lag so that
proposed system probably has some issues, but I
think that it’s important that we establish whether
a CPS is per-cert, or per-hierarchy; if the latter,
then maybe move it into the roots themselves and
save some handshake bytes?
Mike
--
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 on the web visit
https://groups.google.com/a/ccadb.org/d/msgid/public/d71c388f-8853-4a4b-9d49-a9aa4635ef50n%40ccadb.org
<https://groups.google.com/a/ccadb.org/d/msgid/public/d71c388f-8853-4a4b-9d49-a9aa4635ef50n%40ccadb.org?utm_medium=email&utm_source=footer>.
--
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 on the web visit
https://groups.google.com/a/ccadb.org/d/msgid/public/381e5c16-52ab-4ef7-9c0c-ede928dc0a4d%40harica.gr
<https://groups.google.com/a/ccadb.org/d/msgid/public/381e5c16-52ab-4ef7-9c0c-ede928dc0a4d%40harica.gr?utm_medium=email&utm_source=footer>.
--
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 on the web visit
https://groups.google.com/a/ccadb.org/d/msgid/public/CAEmnErckLgLskiQUUzY7ATW6W%3DWfnzMw6GzJKEeh7yu6%2B9frVw%40mail.gmail.com
<https://groups.google.com/a/ccadb.org/d/msgid/public/CAEmnErckLgLskiQUUzY7ATW6W%3DWfnzMw6GzJKEeh7yu6%2B9frVw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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 on the web visit
https://groups.google.com/a/ccadb.org/d/msgid/public/2c0b9fa9-cf19-4a74-8a09-b38f70fffa7dn%40ccadb.org
<https://groups.google.com/a/ccadb.org/d/msgid/public/2c0b9fa9-cf19-4a74-8a09-b38f70fffa7dn%40ccadb.org?utm_medium=email&utm_source=footer>.
--
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 on the web visit
https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mDwnBM0B%2Bj8oAN-GdQ7EiMcTNVWOfzZQgsNSaeZO8u9Zw%40mail.gmail.com
<https://groups.google.com/a/ccadb.org/d/msgid/public/CAAbw9mDwnBM0B%2Bj8oAN-GdQ7EiMcTNVWOfzZQgsNSaeZO8u9Zw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
