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>.
