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.
