The issue of identifying the proper CPS for older certificates raises
the important overall question of how this should be managed on an
industry wide basis:
Note: All examples use numerically invalid values, such as OIDs
beginning with "5." or non-existent dates in the Gregorian calendar.
Some CCADB future policy ideas:
Option 1: The policy extension in each end cert could contain a specific
OID for each policy version, preferably in a systematic way. For
example, if the OID the DV policy of a specific CA sub-hierarchy was
5.4.3.2.1 Then the policy OID for policy release N (consisting of
CPS version N and the CP version it references) could be 5.4.3.2.1.N .
Software running on the CCADB or in services like crt.sh could and
should scan this data periodically to provide useful data and check
for attempts to fraudulently rewrite history.
For this option, CCADB manual entry data would specify the latest
OID and a URL formatting pattern to get any previous policy version by
its number.
TODO: This may or may not interfere with other PKI or root store
policies that require or presume a static OID for the lifetime of the
issuing CA. It also wouldn't work for older policies that were not
mapped in this way.
TODO: This would not reflect subsequent changes in revocation policy
affecting already issued certificates.
Option 2: At any time, the latest CPS document for each overall policy
should contain, in a Mozilla or BR specified standard section number,
a standard formatted table of the issuance date range covered by each
previous CPS version (Assuming a hypothetical rule that a CPS must
explicitly reference the exact applicable CP, if any). Something
like:
55.66.77.88 Past versions of this document:
+-----+----------+------------------+---------------------------+
| ver | eff date | document SHA-512 | Notes |
+-----+----------+------------------+---------------------------+
|1.0 |1996-02-30|xxxxxxxxxxxxxxxxxx| VeryOld hierarchy founded |
| | |xxxxxxxxxxxxxxxxxx| |
|1.1 |1997-02-30|xxxxxxxxxxxxxxxxxx| Timestamping CAs added |
| ............................................................. |
|25.2 |2019-04-31|xxxxxxxxxxxxxxxxxx| Annual review, no changes |
| | |xxxxxxxxxxxxxxxxxx| |
+-----+----------+------------------+---------------------------+
Software running on the CCADB or in services like crt.sh could and
should scan those tables periodically to provide useful data and check
for attempts to fraudulently rewrite history.
For this option, CCADB manual entry data would specify a fixed URL
for the latest version and a URL formatting pattern to get any
previous version by its number. For example
https://repository.example.com/repo/mailCPS-latest.pdf
https://repository.example.com/repo/mailCPS-%V.pdf
TODO: How to specify that a CA (root or intermediary) has been
moved to another policy category, e.g. from "Digicert active S/MIME
roots CPS" to "Digicert revocation-only S/MIME CAs policy" or
"Digicert archived mail signature CAs policy".
TODO: How to specify that some past policy versions used a different
file format (such as text/plain or text/html) for the canonical
binding document form.
Option 3: Upon each policy change or renewal, the CA shall notify the
root programs by appending information similar to the table in option
2, plus a permanent URL in an appropriate CCADB table, visible to the
public. [ This is very similar to current policy ]
CCADB scripts would automatically extract the latest versions
for the old single-version CSV files. CCADB security settings should
prevent CAs from retroactively rewriting history, and corrections
need to be confirmed by the (CA) root program administrators.
Option 4: The repositories on each CA website must include a specific
micro-format to allow programmatically extracting information similar
to the table in option 2, including the URLs.
Software running on the CCADB or in services like crt.sh could and
should scan those pages periodically to provide useful data and check
for attempts to fraudulently rewrite history.
For this option, CCADB manual entry data would specify a URL for
the properly formatted repository page, for example
https://repository.example.com/repo/mailCPS/history/index3.html
(the example.com CA business uses the filenames index.html and
index2.html for previous systematic schemes, all the page forms
are probably generated from the same backend data).
On 03/05/2019 17:36, Ben Wilson wrote:
I'm against having to continually update the exact URL of the CP and CPS in the
CCADB. It's pretty easy to find the current CP and CPS from a legal
repository. Plus, if we point to an exact one in the CCADB, it might not be
the one that is applicable to a given certificate that was issued prior to the
most current CPS. In other words, you should look at when the certificate was
issued and then figure out which CPS is applicable.
-----Original Message-----
From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On
Behalf Of Andrew Ayer via dev-security-policy
Sent: Thursday, May 2, 2019 8:16 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Unretrievable CPS documents listed in CCADB
On Thu, 2 May 2019 18:53:39 -0700 (PDT)
Corey Bonnell via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
As an aside, I noticed that several URLs listed in CCADB are “Legal
Repository” web page URLs that contain a list of many CP/CPS
documents. My recommendation is to slightly amend CCADB Policy to
require CAs to provide URLs to the specific document in question
rather than a general “Legal Repository” page, where it is left up to
the reader to decide which hyperlink on the page is the correct
document.
+1. It's often a real hassle to find the CP/CPS for a CA. Linking
directly to the document would help a lot.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
