Subject: [pkix] Certificate Issuer Transparency Proposal

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 20 Mar 2012 14:35:57 -0400

In response to Stephen's request for a statement of the goals:

Objective: Improve confidence in the system of public CAs by making
certain aspects of CA operations transparent.

We define 'transparent' to mean 'can be audited by any external party
without access to privileged information. Our concern in this
particular proposal is limited to the operation of online HSM devices
used to sign certificates and OCSP responses.

In particular the proposal must address a particular failure
discovered during the DigiNotar case in which a CA lost control of
their HSM and their log files and this state of affairs remained
undetected by the CA for a considerable period of time and was not
known to the general public for a longer period of time.

Proposal:

The following technical proposals would be part of a set of
requirements that all public CAs would be obliged to conform to in
order for their certificates to be recognized.

1) Technical restriction on operation of a CA to ensure an effective
isolation of online and offline certificate signing keys such that:

* Only an Online key may sign EE certificates (other than OCSP certs)
or OCSP responses
* Only an Offline key may sign certificates for online keys (cert
signing certs and OCSP certs)

The first is achieved by mandating use of Basic Constraints and a path
length of 0 for the certificate corresponding to the key used to sign
an EE certificate.

The second constraint illustrates an area where I think we have a big
mess. It is pretty much common sense that the authoritative signer of
a Comodo certificate should be Comodo and no other CA. It is also
pretty clear that there are good reasons why a party other than the
authoritative party might be signing. But neither RFC 5280 nor 2560
makes that distinction and so there are no clear rules for determining
what is an authoritative response.

These create a set of audit checks, e.g.:

* Fail if there any online Cert signing key that does not have a path
length of 0

These also create transparency checks, e.g. :

* Fail if there is an OCSP cert that is issued off a cert with a path
length of 0

2) Technical requirement that the CA maintain a complete log of all
certificates issued and that this condition be transparent to external
observers (but not necessarily the actual contents of the log).

This is achieved by requiring the CA to

* Respond to all OCSP queries with a signed response
* Issue distinct and different responses for the cases 'certificate
not issued' and 'status is not known'
* Issue responses that bind to a specific certificate and not merely a
certificate serial number.

This is to be achieved as follows:

* New OCSP response 'NOT-ISSUED' that allows a range of serial numbers
to be specified (and thus meets the requirement that responses be
capable of being pre-signed if desired)
* New OCSP extension that allows an issued certificate to be specified
by means of a digest (e.g. SHA256) in addition to the serial number
* Limit the time period for which the notBefore date in a cert may be predated.

These create a series of transparency checks:

* Fail if a certificate is discovered for which an inconsistent
NOT-ISSUED OCSP response is returned [Note that predating of notBefore
creates issues here]
* Fail if a request for a random certificate results in any response
other than NOT-ISSUED

Note that mere failure of a transparency check does not mean the
automatic end of a CA root. It is a signal that something MAY be wrong
and that further investigation is required.

-- 
Website: http://hallambaker.com/

---

From: Erwann Abalea <[email-masked]>
Date: Tue, 20 Mar 2012 20:16:15 +0100

Bonsoir,

2012/3/20 Phillip Hallam-Baker <[email-masked]>
[...]

> length of 0 for the certificate corresponding to the key used to sign

Not exactly. This condition (basicConstraints:pathLen=0) only disallows a
CA with a pathLen different than 0 to sign an EE cert. There's no "online"
vs "offline" here. But as implied by the phrasing, let's consider "online"
for "pathLen=0 CA certs", and "offline" for "pathLen != 0 CA certs" from
now.

Are you proposing that CAs can only sign other CAs *or* EEs, but not both?
(exclusive or)

Are you proposing that a CA used to issue EE certs cannot sign an OCSP
responder certificate? (see below)

> * Fail if there is an OCSP cert that is issued off a cert with a path

This rule forbids the creation of a designated OCSP responder for an
"online" CA. You're therefore reserving OCSP designated responders to
"offline" CAs, where CRLs are sufficient.

[thinking further] Are you proposing that an OCSP responder can only be the
CA itself (i.e. same name), with a dedicated certificate, signed by the
parent CA (an offline one), as opposed to a self-issued certificate? I
wanted to test that case with different toolkits/products, but it takes
time.

> * Respond to all OCSP queries with a signed response

This is already the case as per RFC2560, for definitive responses (good,
revoked, unknown). This cannot be enforced for *all* responses (i.e.
malformedRequest, internalError, tryLater, sigRequired, unauthorized)
unless you want to expose the OCSP responder to DOS.

[...]
The whole threads need to be read again, but right now my opinion is that
all this is either not necessary or counter productive (could slow OCSP
adoption). My opinion may be biased (I'm a CA, and host several CAs).

-- 
Erwann.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 21 Mar 2012 16:49:13 -0400

>known to the general public for a longer period of time.

PHB,

I removed the rest of your message in my reply, because it begins to 
describe a solution, not refine the problem  statement. This is not 
an endorsement or criticism of what you state above, just an 
observation about what is appropriate for the requirements doc.

The doc also needs to describe perceived constraints on the solution 
space, and explain why the author believes these constrains apply.

Looking at the stated objective above, I am not convinced that it is an ideal
start for a problem statement, although one could re-word it to be 
so, e.g., saying that users have lost (are loosing?) confidence in 
the current public CA system and we need to address that problem. 
Then, you talk of the need for greater transparency, which means 
you're already heading down the solution path, after just a single 
sentence problem spec.  I think that needs more thought too.  Then 
you bring in operation of HSMs as an area of particular interest. 
That seems awfully narrow. Bringing up the DigiNotar case as an 
example is fine, as it's good to explain a general problem 
characterization with specific examples.

Just a few thoughts for you, and for Brennan as you start work on 
problem statement docs.

Steve