Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 1 Nov 2011 15:20:43 -0700 (Pacific Daylight Time)

On Tue, Nov 1, 2011 at 5:18 AM, Miller, Timothy J. <[email-masked]> wrote:
> On 10/28/11 11:14 AM, "Kyle Hamilton" <[email-masked]> wrote:
>>I have no problem at all with improving OCSP, as a separate item.  I
>>really want to improve it, actually.  The problem is that by
>>definition, any OCSP responder which can respond with a "does not
>>exist" will be required to respond in that manner for any and every
>>certificate serial number which is not listed on the CRL.  CRL cannot
>>meaningfully feed such a responder.
>
> Since OCSP services can be delegated, the responder may not have access to
> the CA database.  A responder without access to the CA database can *only*
> respond with 'revoked' or 'good.'  Technically the 'good' answer is 'I
> don't know otherwise' because it represents the absence of data.

A responder without access to the CA database can answer REVOKED or UNKNOWN.

I want to do away with the technical limitations which require non-CA OCSP responders to answer UNKNOWN, by providing a means to transfer comprehensive revocation information (including "this certificate is not revoked") from the CA to the non-PKI OCSP server.

> Don't presume that a responder is synonymous with a CA.  There are
> compelling reasons to divorce these services, and real PKIs do so in
> practice.

There are indeed compelling reasons to divorce these services.  As a result, there are indeed compelling reasons to create a format by which non-CA OCSP responders can know to answer GOOD or REVOKED instead of UNKNOWN or REVOKED.  The former happens in industry.  The latter doesn't happen because PKIX-WG wishes to avoid creating it with every excuse from "it won't solve the problem" to attacking the measure.

I know that it won't solve the problem.  I also know that the problem cannot be solved without intense engineering effort.

Instead, I want to provide a means for implementations to copy+paste their CRL code with minimal changes to support the new semantics.

-Kyle H

---

From: "Kyle Hamilton" <[email-masked]>
Date: Tue, 1 Nov 2011 15:22:14 -0700 (Pacific Daylight Time)

Again, please:  Do not let perfection become the enemy of any improvement at all.

On Thu, Oct 27, 2011 at 12:59 PM, Peter Sylvester <[email-masked]> wrote:
> you just can add an extension that says "when I said revoked, it really
> means more, it doesn't even exist"

True.  I suggest something like this elsewhere in the thread.

(At least there are some discussions going on now.)

>> The OSCP responder does not need access to the CA, just a list or set of
>> lists for all the issued certificates.

...such as my proposal...

> It needs some information that can be used to verify if a cert had been
> issued.
> a strong one way function (in oder to avoid the word hash) towards that info
> to see
> whether a cert is valid for example.

I like the 'for example', as it implies that there are other ways to approach the problem.  (I prefer the term 'digest'.)

As I said, I propose what I do simply so that an extremely easy-to-implement (copy+paste with minimal editing) incremental improvement can be made.  I believe that reducing the threat space[1] with a mechanism that enforces desirable semantics[2] in a way that people already understand[3] is preferable to requiring a major version bump at the least, much less additional debugging time before being ready to roll out to the public... and that only after PKIX finally standardizes something it hasn't been able to in the past decade, with additional mandates that don't address what the applications need and can implement /right now/.

I believe that it's more desirable to get people in the mood to improve things at all with small, easily-understandable engineering steps, than to demand that they accept yet another overblown "standard" that achieves at best the zero security effect of no implementation and at worst the negative security effect of immature technology failure during its roll out.  Once we get the implementers in the mode of looking for a whitelist, we can improve it with strong ID data for issued certificates and provided as a CRL/CMR extension.  Maybe something like:

-- contains one entry for each certificate
CertificateIssuanceList ::= SEQUENCE  (0..MAX) of CertificateIssuanceEntry;

-- contains multiple algorithm/digest tuples for one certificate
CertificateIssuanceEntry ::= SEQUENCE (0..MAX) of CertificateIssuanceAtom;

-- individual algorithm/digest tuple
CertificateIssuanceAtom ::= SEQUENCE {
    DigestAlgorithmOid OBJECT IDENTIFIER,
    DigestValue OCTET STRING }

This would permit the same certificate to be identified strongly with multiple digest algorithms, which would permit stronger verification by a wider variety of clients than provided by a single algorithm.  RPs would ignore hashes with algorithms they don't trust, and the CA could provide multiple hash values for diverse consumers with the same semantics in the same structure.  (Personally, I'd check all of them, under the theory that they will all test true even if I can't rely on the security of any one or more of them.  If there's any mismatch at all, even in the broken digests, then something's wrong.)  Notably, it wouldn't disclose the serial number of the matching certificate.

In the meantime, though, there's no reason that the CRL couldn't be usefully extended with 'removeFromCrl'.

The DigiNotar sleepwalk attack is going to become a much larger problem unless we take action now to stop it, and Mozilla will not do anything without standards body backing.  Please, I know that this isn't optimal or ideal, but it's an important first step to improving the infrastructure as a whole.

Incremental improvement, not perfection or bust.  PKIX-WG was wrong 10 years ago about what it thought the perfect and ideal system would be, and there's no chance that any new monolithic standard will correctly predict the future 10 years from now.  There are major problems which prevent the PKIX standards from taking root, and the body's inflexibility and unwillingness to accept that its standards are broken in fundamental ways is the reason they have remained unaddressed.  That self-reverential "reality should be this way" view prevents it from considering or accepting incremental changes to help address -- as stopgap measures -- the security holes which permitted the compromise of a CA to cause a person's death.  PKIX-WG was warned about this vector in the past, and did nothing to defend it.

Let's look at the costs of a public CA distrust:

- the CA's death, thus the deprivation of a taxpayer and lower tax revenues from its newly-unemployed employees, and thus a Gross Domestic Product hit for the entire state.
- the costs to every site enrolled in the CA's PKI of having to get recertified immediately, which is an instant priority given that browser users (presumably and hopefully) won't go to uncertified sites.  They can't make sales during the time they're uncertified, and each will instantly lose a portion of their customer bases as a result.
- the costs to every other CA which must have enrollment channels sufficient to handle the influx of new enrollees.
- the costs to everyone who uses or shops at the sites newly uncertified.  Imagine if Thawte SGC CA or Equifax Secure CA were compromised.  (Not familiar with Thawte SGC CA?  That's the one that issues to mail.google.com.  Equifax Secure CA issues to docs.google.com.)
- the costs to the entire CA/Browser trust model and consumer confidence.

We cannot sit back and say "that's the cost the certified party pays for choosing a poorly-run CA".  There are simply far too many people who are affected, with far too much cost to each one.  (Besides, even audited CAs make mistakes.  The only thing that consumers have to rely upon are audits, and those audits obviously don't catch everything.  We should allow them to continue to do their job, and provide them a means to help end entities/relying parties protect themselves.)

-Kyle H

[1] Implementations MUST be able to handle serial numbers up to 160 bits, or 20 bytes.  (Notably, a serial number might require a 21-byte encoding, since it's an integer and not a bit string or octet string.)  This means that the threat space for CAs which enforce random serial numbers is (exp(2,160) - count(CRL)), or (with 65,536 entries on the CRL) around 2**146.  The threat space for CAs which alter their CRLs to this spec is becomes (count(CRL,entriesRemoved)), which instantly removes 2**152 or so possibilities.

[2] Desirable semantics include "if a particular serial number on this list is found to have an invalid certificate associated with it, the CA can instantly and decisively take action by revoking and reissuing where appropriate", and "the CA knows that this list is more accurate than providing simple revocation data." Additional desirable semantics are the capacity for internal OCSP to answer for serial numbers[4] known to not be in the list as "never issued".  If the generation of this list were periodically entry-by-entry verified in a process completely separate from the technical operation of the CA, it could provide an extra, affirmative, records-based and thus not easily technically defeated approach to increase the probability of detecting CA compromise, and for both the enrollee and the RP successfully defending against CA compromise.

[3] People understand the CRL.  More importantly, implementors understand the CRL.  We should build on what we've got.  Once one gets past idealistic preconceived notions of "this is what this is for and never anything more because it just is" and starts looking toward making it all work, one understands that the best changes are the least changes in an already overly-complex and over-budget system of dubious actual utility.

[4] Once a spec comes out (still waiting for I-Ds) that will permit the stronger authentication of certificates, it will be a major implementation task for an immature technology.  In the meantime, some protection -- and it is protection, for both the CA and the end entities involved -- is better than none.  Do not let the perfect become the enemy of the good.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 2 Nov 2011 12:10:51 +0000

>A responder without access to the CA database can answer REVOKED or

Current OCSP clients treat UNKNOWN as a failure.  UNKNOWN means the
responder cannot provide an answer; e.g., the responder doesn't have
current data, or the responder is not authorized to respond for that
issuer.  

Recall that the authoritative statement of validity is the CRL.  CRLs do
not communicate cert existence.  A responder seeded with a CRL has its
answer--the cert is good.

If the OCSP query is for a non-existent serial number, the responder's
answer is irrelevant anyway because the cert will fail path validation.
So I really don't see why this is a concern to you.

-- T

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 2 Nov 2011 12:56:59 -0700 (Pacific Daylight Time)

> current data, or the responder is not authorized to respond for that

Or "the responder doesn't have information on what serial numbers were actually issued, so it cannot authoritatively answer VALID".

> answer--the cert is good.

The CRL is completely insufficient for this need.

> So I really don't see why this is a concern to you.

No, it won't, not if the CA's hardware was induced to do something that wasn't authorized.

The records are the only legitimate authoritative source for enrollment information, and if a CA's doing its job right it also has every certificate (or at least certificate serial number, since PKIX-WG never provided any other means to identify certificates) ever issued to that entity and its disposition.

A person -died- because of this.  So I don't really see why this isn't a concern to you.

-Kyle H

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 03 Nov 2011 09:02:29 +1300

"Miller, Timothy J." <[email-masked]> writes:

>Current OCSP clients treat UNKNOWN as a failure.  

No, current OCSP clients treat Unknown as pretty much anything.  In particular
since Unknown != Revoked, many treat it as "Not revoked" -> "Good" (OCSP's
"Good" doesn't actually mean that the cert is good, merely that it's not on a
CRL).

Oh, and responders are no better, they may report a cert as "Good" (meaning
"Not revoked") if it's not on a CRL.  Or pretty much anything else, depending
on the responder and how it's configured.

Peter.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 2 Nov 2011 13:27:58 -0700 (Pacific Daylight Time)

> "Good" doesn't actually mean that the cert is good, merely that it's not on a

This is why we need a CRL-like whitelist, instead of a blacklist, to prove that a certificate was in fact issued in accordance with the policy.

> on the responder and how it's configured.

Which is why OCSP needs to be fixed, by providing the responders with authoritative lists of valid certificates.

-Kyle H

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Nov 2011 19:57:32 -0400

No, the CRL is only authoritative for invalidity.

Looks to me like you are going to have a problem when we fix this. That is
your problem, not ours.

We can fix it here or elsewhere but you have no veto on it being fixed.

And the 'worlds biggest PKI' cost how much per cert? Not a model Io feel
like following.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Nov 2011 20:08:48 -0400

On Wed, Nov 2, 2011 at 3:56 PM, Kyle Hamilton <[email-masked]> wrote:

> Or "the responder doesn't have information on what serial numbers were
> actually issued, so it cannot authoritatively answer VALID".
>
>
> The records are the only legitimate authoritative source for enrollment
> information, and if a CA's doing its job right it also has every
> certificate (or at least certificate serial number, since PKIX-WG never
> provided any other means to identify certificates) ever issued to that
> entity and its disposition.
>

I am not aware of a death being reported linked to the DigiNotar incident.
Perhaps you can provide a source. Several people have claimed that it
'must' have resulted in deaths but these are not people who I know to have
close connections with the green movement in Iran.

Communications compromise due to SSL CA breach are serious but only one
compromise vector. Lost/confiscated laptops and mobiles are a much bigger
problem. Everyone involved knows that the authorities can and do arrest
people and force them to disclose contact information, passwords etc.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 2 Nov 2011 17:44:02 -0700 (Pacific Daylight Time)

On Wed, Nov 2, 2011 at 5:08 PM, Phillip Hallam-Baker <[email-masked]> wrote:
> Perhaps you can provide a source.

The death of a corporate person, which body was forced insolvent, dismantled and sold for scrap.  This is documented.  If you want references, perhaps you should read the draft you're commenting on (which actually does explain this).

The death of a corporation is not to be taken lightly.  It directly impacts the lives of all of its employees, deprives the state of a taxpayer, and reduces the amount of tax revenue the state can extract from that corporation's employees.

> Several people have claimed that it 'must'
> have resulted in deaths but these are not people who I know to have close
> connections with the green movement in Iran.

This is a red herring.  I'm not going to approach what the attacker did with the certs.  That's far outside the realm of what PKIX can control.

What PKIX can control is how easy it is to get information that the certificate was never validly issued.  This is something which it does not currently do, and which my draft is intended to correct.

(I'm also looking at the fact that there currently exist two main sources of OCSP responses: the issuer and the relying party.  The issuer currently can issue REVOKED for everything it knows wasn't issued, but the relying party's OCSP responder doesn't know what wasn't issued so it cannot ever legitimately answer VALID.  My draft is a format to get information from the issuer to the relying party's OCSP server more than anything else.)

> people and force them to disclose contact information, passwords etc.

Red herring.  The argument you propose is akin to demanding that the banks which provide payment services for a multiple parties not bother with securing the infrastructure which permits payments, simply because 'everyone involved knows' that the state can mandate disclosure anyway.  It is completely outside of the realm of what any engineering task force can do, much less PKIX-WG.

"Lost laptops" and "lost mobiles" are, indeed, a much bigger problem.  They are also completely out of scope for what this draft is intended to address.  (I've other ideas that will be drafted to help deal with this.)

The world has never been changed by a nay-sayer.  The world has never actually been improved by a nay-sayer.  There's a valid need for a whitelist, and PKIX was warned as a body that by not providing defense in-depth (not providing any means at all for defense-in-depth, actually) the system would break.

Now, it's time to clean up the mess that PKIX-WG has left CAs, software manufacturers, and their interested and relying parties with.

Since IETF is "Internet ENGINEERING Task Force", I seek comments from implementors and engineers.  

-Kyle H

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Nov 2011 21:01:56 -0400

On Wed, Nov 2, 2011 at 8:44 PM, Kyle Hamilton <[email-masked]> wrote:

> The death of a corporate person, which body was forced insolvent,
> dismantled and sold for scrap.  This is documented.  If you want
> references, perhaps you should read the draft you're commenting on (which
> actually does explain this).
>

Corporations are not people. No really, they are not.

This country already fought one civil war over the belief that people were
property. Now there are people thinking that property is people. Both ways
of thinking are wrong.

> The death of a corporation is not to be taken lightly.  It directly
> impacts the lives of all of its employees, deprives the state of a
> taxpayer, and reduces the amount of tax revenue the state can extract from
> that corporation's employees.

In this case we have real people's lives at stake.

Confusing the issue with hyperbole trivializes the issue.

---

From: Stephen Wilson <[email-masked]>
Date: Thu, 03 Nov 2011 12:33:31 +1100

Whoah whoah whoah! PKI is already littered with pseudo legal nonsense, 
like "non repudiation".  But confusing corporations with natual persons 
is a new low.  I haven't followed the engineering pros and cons of this 
thread -- only for lack of time -- but I observe that arguing for 
technological changes because a corporation as "-died-" [shrill emphasis 
in the original] devalues the debate to near zero.

Stephen Wilson
Lockstep

http://lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

On 3/11/2011 11:44 AM, Kyle Hamilton wrote:
>>> A person -died- because of this.  So I don't really see why this 
>>> isn't a
>>> concern to you.
>>
> references, perhaps you should read the draft you're commenting on 
> (which actually does explain this).
>
> taxpayer, and reduces the amount of tax revenue the state can extract 
> from that corporation's employees.
>
> This is a red herring.  I'm not going to approach what the attacker 
> did with the certs.  That's far outside the realm of what PKIX can 
> control.
>
> What PKIX can control is how easy it is to get information that the 
> certificate was never validly issued.  This is something which it does 
> not currently do, and which my draft is intended to correct.
>
> (I'm also looking at the fact that there currently exist two main 
> sources of OCSP responses: the issuer and the relying party.  The 
> issuer currently can issue REVOKED for everything it knows wasn't 
> issued, but the relying party's OCSP responder doesn't know what 
> wasn't issued so it cannot ever legitimately answer VALID.  My draft 
> is a format to get information from the issuer to the relying party's 
> OCSP server more than anything else.)
>
> Red herring.  The argument you propose is akin to demanding that the 
> banks which provide payment services for a multiple parties not bother 
> with securing the infrastructure which permits payments, simply 
> because 'everyone involved knows' that the state can mandate 
> disclosure anyway.  It is completely outside of the realm of what any 
> engineering task force can do, much less PKIX-WG.
>
> "Lost laptops" and "lost mobiles" are, indeed, a much bigger problem.  
> They are also completely out of scope for what this draft is intended 
> to address.  (I've other ideas that will be drafted to help deal with 
> this.)
>
> The world has never been changed by a nay-sayer.  The world has never 
> actually been improved by a nay-sayer.  There's a valid need for a 
> whitelist, and PKIX was warned as a body that by not providing defense 
> in-depth (not providing any means at all for defense-in-depth, 
> actually) the system would break.
>
> Now, it's time to clean up the mess that PKIX-WG has left CAs, 
> software manufacturers, and their interested and relying parties with.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix

---

From: "Kyle Hamilton" <[email-masked]>
Date: Wed, 2 Nov 2011 18:37:37 -0700 (Pacific Daylight Time)

> Corporations are not people. No really, they are not.

As long as the state disagrees, I must go with the state definition.  If I don't, then I'm living in a psychotic, delusional fantasy world which has no bearing on reality.

> property. Now there are people thinking that property is people. Both ways

In principle, I agree with you.  In practice, I can't.  We must live with the living, and respect the dead who got us to this state.

>> impacts the lives of all of its employees, deprives the state of a taxpayer,
>> and reduces the amount of tax revenue the state can extract from that
>> corporation's employees.
>

Given that the IETF was set up under state contracts (DARPA), I must go with the state definition, because that's how the law works.  Don't like it?  Make political change in your sovereign, not the IETF.  NOTHING will be changed by your complaining that it's wrong.

Also, corporation-as-person has a really nice side effect profile: it permits discussion of "the RP's OCSP responder" which is instituted by corporate governance.  Until a trustworthy (with issuance data) publicly-available subscription OCSP service exists, I'm going to assume that the reason for RP-based OCSP is to spread revocation information throughout the corporate body like an inoculation.

That is where the disconnect between known-issued and known-revoked certificates is least obvious and particularly damaging.  The DigiNotar incident showed that the PKIX mechanisms were insufficient to meet the needs of the end-user.  Corporate risk managers had to instantly get new certificates, and thousands if not hundreds of thousands of guilders were spent by people (including corporations, via their paychecks to the natural people who perform the corporation's work) who were certified and had to do a new enrollment as a result.

Now, DigiNotar has really gotten people's attention because now it's not just the corporations who are hurt by this.

Hyperbole or not, I prefer to live in reality, where (however regrettably) the law says that corporations are people.  I'm not going to labor under any psychotic delusion that they have no standing under the law and cannot bring suit in their own names (which is part of the state definition of 'person', incidentally).  They are people, with birth (filing of articles of incorporation) and death (dissolution of corporation), until the law does not recognize them as such.

-Kyle H

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 03 Nov 2011 14:41:47 +1300

Phillip Hallam-Baker <[email-masked]> writes:

>property. Now there are people thinking that property is people. Both ways of
>thinking are wrong.

Right or wrong, most (all?) countries in the world recognise corporations as
legal people, just not natural people.  OTOH this is getting way, waaaay off
topic.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 2 Nov 2011 22:56:01 -0400

Your original claim was misleading and offensive.

Some of us here have a much closer relationship to the events in question
than you imagine. Do not take these matters lightly if you want to be taken
seriously here.

On Wed, Nov 2, 2011 at 9:37 PM, Kyle Hamilton <[email-masked]> wrote:

> As long as the state disagrees, I must go with the state definition.  If I
> don't, then I'm living in a psychotic, delusional fantasy world which has
> no bearing on reality.
>
>
> In principle, I agree with you.  In practice, I can't.  We must live with
> the living, and respect the dead who got us to this state.
>
>>> taxpayer,
> Given that the IETF was set up under state contracts (DARPA), I must go
> with the state definition, because that's how the law works.  Don't like
> it?  Make political change in your sovereign, not the IETF.  NOTHING will
> be changed by your complaining that it's wrong.
>
> Also, corporation-as-person has a really nice side effect profile: it
> permits discussion of "the RP's OCSP responder" which is instituted by
> corporate governance.  Until a trustworthy (with issuance data)
> publicly-available subscription OCSP service exists, I'm going to assume
> that the reason for RP-based OCSP is to spread revocation information
> throughout the corporate body like an inoculation.
>
> That is where the disconnect between known-issued and known-revoked
> certificates is least obvious and particularly damaging.  The DigiNotar
> incident showed that the PKIX mechanisms were insufficient to meet the
> needs of the end-user.  Corporate risk managers had to instantly get new
> certificates, and thousands if not hundreds of thousands of guilders were
> spent by people (including corporations, via their paychecks to the natural
> people who perform the corporation's work) who were certified and had to do
> a new enrollment as a result.
>
> Now, DigiNotar has really gotten people's attention because now it's not
> just the corporations who are hurt by this.
>
> Hyperbole or not, I prefer to live in reality, where (however regrettably)
> the law says that corporations are people.  I'm not going to labor under
> any psychotic delusion that they have no standing under the law and cannot
> bring suit in their own names (which is part of the state definition of
> 'person', incidentally).  They are people, with birth (filing of articles
> of incorporation) and death (dissolution of corporation), until the law
> does not recognize them as such.
>
> -Kyle H
>

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Nov 2011 09:15:14 +0200

On 11/3/11 3:37 AM, "Kyle Hamilton" <[email-masked]> wrote:

>As long as the state disagrees, I must go with the state definition.  If
>I don't, then I'm living in a psychotic, delusional fantasy world which
>has no bearing on reality.

No, the state does not disagree. Corporations are variously called
"fictitious person", "legal entity", or "legal person". That does not mean
that they are people. They don't get the same rights as real people. The
legal fiction is only necessary so that corporations can own property,
take on obligations (contracts), sue, and be sued.

I can own a corporation, but I can't own a natural person. If I decide to
close a corporation that I own (make it "die" by your words) I don't think
I'm going to jail for murder.

It's enough to say that the DigiNotar incident had economic consequences.
That's a good enough reason to take action without talking about dead
people. 

I also think it's wrong to focus on the damage to DigiNotar. They were
hacked, their customers and partners lost confidence, and they had to shut
down. Businesses not living up to their customers' expectations and having
to close down is a common event in any industry, and is not unique to the
security industry. We should devote greater attention to the damage
(economic or physical) that is suffered by relying parties and end
entities - the web surfers and the website owners. Those are unique to the
PKI industry, so they're directly related to this working group.

As an analogy, if we were writing standards for bullet-proof vests, and
there was this company that made bad vests and sold them to police forces
and the army, we would be worried about the police officers and the
soldiers, who might suffer some real death more than about the
manufacturer with its fictional person death.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 3 Nov 2011 12:01:54 +0000

>No, it won't, not if the CA's hardware was induced to do something that

If the CA is compromised, the game is over and whitelisting won't save it.
 A compromised CA will generate false CRLs and whitelists equally well.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 3 Nov 2011 12:23:09 +0000

So let me summarize the problem(s) that I think you're trying to address:

1. A CA is defrauded and issues certificates (e.g. Verisign, 2001).

2. A CA is compromised and issues certificates (e.g. DigiNotar et.al.,
2011).

3. A Subscriber certificate fraudulently claims to be issued from a CA
where it was not, in fact, issued.

In (1), blacklisting the issued certificates works; whitelisting gains you
nothing.  When the fraud is detected, the certificates are revoked, the
CRL works its way through the infrastructure, and eventually no-one trusts
the fraudulent certificates.  Whitelisting is ineffective because the
fraudulent certificates *are on the whitelist* (at least until they are
discovered, at which point they move to the blacklist).

In (2), neither blacklisting nor whitelisting the issued certificates is
effective because the CA is authoritative for the both.  A malicious
trusted user of the CA can remove revoked certificates from the CRL, and
can insert certificate records into the database.  The only effective
response in this case is to blacklist the CA, which invalidates anything
that CA has issued.

In (3), the fraud should be detected by certificate path discovery.  The
claimed issuer won't be in the discovered path, and the whitelist is never
referenced.  What they relying party does with this information is their
own decision.

CRLs may be insufficient in some cases; e.g., the Verisign incident
involved code signing certificates which for good or ill have a special
validation logic, and a general lack of CRL checking meant that DigiNotar
CA revocation weren't being honored.  However, the 'fix' for both cases
was just another form of blacklisting (e.g., see "Untrusted Certificates"
in any Windows CAPI instance).

Finally, we know with CRLs that too many relying parties simply ignore
them.  Why would whitelists (CVLs?  NegaCRLs?) be any different?  What
compels a relying party to check a whitelist when it currently doesn't
check a blacklist?

And on a personal note, I'm not trying to 'veto' anything.  IETF doesn't
work that way.  I'm just trying to understand what the goal is and give my
opinion.

-- T

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Nov 2011 08:37:46 -0400

>  A compromised CA will generate false CRLs and whitelists equally well.

That was the old thinking. It is not the current thinking.

In the DigiNotar case, whitelisting could have allowed the issue to be
detected much earlier.

The authoritative source for status information is and always has been the
CA certificate database. At present the specs are defective in not
supporting disclosure of 'does not exist'.

I don't see any valid technical reason not to do so. The third party
responder thing seems to me to be a commercial issue, not a technical one.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 3 Nov 2011 12:57:14 +0000

>That was the old thinking. It is not the current thinking.

Maybe not yours, but so far I can't seem to grasp exactly why you think
that way.

>In the DigiNotar case, whitelisting could have allowed the issue to be

Ok, how?  Give me a scenario.

>The authoritative source for status information is and always has been
>the CA certificate database. At present the specs are defective in not

DigiNotar and Comodo were attacked through compromised Registration
Authority account credentials.  The attacker in these cases was acting as
an authorized RA.  This means that as far as internal processes at the CA
are concerned, the fraudulent certificates were properly issued and had
entries in the CA database.

Detecting which certificates were frauds required checking the CA database
against data external to the CA--e.g., paperwork, email, payment records,
etc.--because the CA database itself was at question.  So where does the
whitelist fit in again?

-- T

---

From: Rob Stradling <[email-masked]>
Date: Thu, 3 Nov 2011 13:10:58 +0000

> Ok, how?  Give me a scenario.

http://isc.sans.edu/diary.html?storyid=11512

"Some of the CA servers have had parts of their logs deleted, leading to 
DigiNotar not knowing what certificates were issued."

"The OCSP server's working at DigiNotar has been reversed since Sept 1st. 
Normally these servers respond with good to all certificates except those on 
the CRL (a blacklist). The OCSP now operates in whitelist mode: it will call 
all unknown certificates signed by DigiNotar as revoked (a whitelist). 
Hence we need to make sure to use the OCSP server to validate DigiNotar 
certificates -should we want/need to- and not rely on the published CRLs 
anymore."

> entries in the CA database.

In the Comodo case, yes, the fraudulent certificates did have entries in our CA 
database.  They were detected and revoked within a few hours of being issued.

> etc.--because the CA database itself was at question.  So where does the

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 3 Nov 2011 09:51:59 -0400

"logs deleted"?  If the CA does not have a database, and database
backups, and audit logs, and offsite audit log backups, showing what
certificate serial numbers have been signed (only one of which would be
needed to reconstruct current CRLs), that pretty much makes the case
that neither a whitelist nor a blacklist is worth the bits it is printed
on.  Given the lack of even rudimentary availability controls, what
would make any RP believe that a cert, listed on a whitelist or not, has
any validity?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Rob Stradling

"The OCSP server's working at DigiNotar has been reversed since Sept
1st. 
Normally these servers respond with good to all certificates except
those on the CRL (a blacklist). The OCSP now operates in whitelist mode:
it will call all unknown certificates signed by DigiNotar as revoked (a
whitelist). 
Hence we need to make sure to use the OCSP server to validate DigiNotar
certificates -should we want/need to- and not rely on the published CRLs
anymore."

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Nov 2011 13:43:09 -0400

No, DigiNotar was owned by the attacker completely. They were able to issue
certs and to delete the issue logs.

It is not a compromise that should be remotely possible at an audited CA,
there are certainly other issues there. But even if we secure all
commercial CAs to absolutely prevent a repeat we cannot guarantee that we
won't see a repeat on private issue and we can't expect to convince folk
meddling with the CA cert model to accept the assurances either.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 3 Nov 2011 13:44:24 -0400

To enable the inconsistency in the CA response to be detected more quickly
so that the euthanasia squad can be called in quicker.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 3 Nov 2011 18:57:40 +0000

>certificates -should we want/need to- and not rely on the published CRLs

This is a valid *response* strategy in the DigiNotar case because of the
specifics of the attack; switching DigiNotar's responder to whitelisting
essentially functions as a bulk revocation of everything but certs issued
prior to the compromise (which are assumed valid) without having to
positively identify those certs individually.  This is necessary because
the corrupted CA data meant that the attacker-issued certs simply can't be
identified; even given external data with which to validate an issuance,
the issuance data is missing, so revocation simply can't be done.

However, from a *pre-attack detection* standpoint, I don't see how
whitelisting helps.  The attacker corrupted the CA data for unknown
reasons; indeed, he may simply have been erasing record of the intrusion,
and cast too wide a net.  A more careful attacker may not do this, in
which case whitelisting doesn't yield a benefit as the attacker-issued
certs *are on the whitelist*.  Further, whitelisting would not be
necessary as a response in cases where the CA data is preserved because
the data to support revocation is available, as we see in Comodo's case. I
won't dispute that it may still be convenient.

What's most telling to me in the DigiNotar case is that whitelisting was
accomplished with no change to the standard or client implementation;
DigiNotar simply altered the behavior of the responder.  This tells me
that a whitelisting feature of the protocol simply isn't needed.  If you
want to run your responder as a whitelist you already have everything you
need, just plop a statement or two in your CP and/or CPS and get on with
it.

-- T

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 04 Nov 2011 10:23:34 +1300

>In the DigiNotar case, whitelisting could have allowed the issue to be

Would it?  Diginotar went to some lengths to cover up the problem, and
according to the recent EFF results, other CAs have also covered up
compromises.  If the CA doesn't want to admit that there's a problem then a
whitelist won't help.  The question really becomes "how far will a CA go to
maintain the illusion that it's providing a security service to users"?

Peter.

---

From: Martin Rex <[email-masked]>
Date: Fri, 4 Nov 2011 19:55:18 +0100 (MET)

> maintain the illusion that it's providing a security service to users"?

It might have, but does not need to.

A whitelisting approach is primarily a means of damage control for
the CA and recognizing the facts and realities of a desaster recovery
process.  Having a "last-known-good" backup from some time in the
past, and having to re-audit accounting logs for newer records
in order to tell incorrect or fraudulent stuff apart from the
good stuff is IMO nothing new or special, that is a pretty normal
concept in the business and accounting world.

While whitelisting could be easily and quickly made to work with
an OCSP responder that is colocated near or hosted by the CA and
with access to the issuing database, it does not seem to work with
the idea of "local OCSP responders".

Conceptually, local OCSP responders work on CRLs and therefore
there is a time delay between informtion published by the CA and
information known ot local OCSP responders.  Having local OCSP
declare a new certificate as "revoked (never issued)" for a few
hours after issue looks like a problem 

White-listing based on cryptographically strong identifiers
(such as a certificate hash) can help a CA to perform damage-control,
the benefit for the RP is really not that great.  Essentially,
it represents an ad-hoc alternative signature on an existing
credential with a different signer cert -- but that has the
prerequisite that the break-in was noticed, stopped, and the
CA has regained control over its operations and an OCSP
responder credential around that is still trustworthy.

There is no change to the vulnerability for RPs before the CA break-in
is detected and stopped.  There is no protection if the CA does
not clean up appropriately, and neither when the fraudulent issuance
was coerced (i.e. known to the CA) by some vicious governmental or
other agency--independent of the (il)legality of such coercion
under whatever jurisdiction.

My personal conspiracy theory for the particular attack on DigiNotar
and a few other CAs would be that it was a governmentally backed
intelligence operation.  But rather than looking for dissidents as
primary targets, this may have been an attempt to identify
foreign undercover agents that were trying to blend with the
crowds of webmail customers for their secret communication.
While I would expect those agents to use additional crypto inside
(i.e. inside TLS) for their actual communication, blending/hiding
that you're using encrypted Email and which peers you're communicating with
is *much* harder if the observer is able to strip the TLS encapsulation.

Of course, if they find information about dissidents while listening
in to that communication of their target group, they will likely use
that as well.  But I would find it strange if they wasted their
attack capabilities (which work only for a short time) for
non-professional folks that they could probably monitor with
traditional (physical) surveillance just as effectively.
For me, this looks like a Stuxnet-related investigation.

-Martin

---

From: [email-masked]
Date: Mon, 7 Nov 2011 10:06:17 +0100

In order to take advantage of OCSP responders which would be able to use 
white lists of certificates, 
looking back at comments made by Peter Sylvester, it is not mandatory to 
support a new certStatus,
as I previously mentioned, but simply a new singleExtension.

This new single extension SHOULD be supported as soon as the responder 
uses white lists of certificates
( I would even say "SHALL  be supported within 2 years from now" to allow 
a smooth migration).

This single extension would indicate something like "cert. status checked 
using white lists".

Although not mandatory, this new extension could also include the hash 
value of the certificate computed 
with a hash function chosen by the OCSP responder.

In order to illustrate the difference of behavior between an OCSP 
responder using CRLs and 
another one using white lists of certificates in case the query is about a 
certificate which has never been issued.

a) OCSP responder using CRLs

certStatus = good

b) OCSP responder using  white lists of certificates

certStatus= revoked

singleExtension "cert. status checked using white lists" present.

Should this become a new work item for the PKIX WG ?

Denis 

De :    [email-masked]
A :     [email-masked]
Date :  27/10/2011 10:22
Objet : Re: [pkix] An alternative proposal Was: Fwd: New Version 
Notification    for draft-hamilton-cmr-00.txt
Envoyé par :    [email-masked]

Phil, 

We both agree that the problem comes from the fact that OCSP does not have 
a proper response code for 'does not exist'; 

Since CertStatus is a CHOICE, we would need to move to OCSP v2 to add a 
new choice. 

However, simply adding this response code to OCSP v2 would not be 
sufficient. 

It would be necessary to advertise to the client that a given OCSP server 
has a direct access to the CA list of issued certificates,
and hence is is able to send back this new response code. 

I would simply propose that we advertise this in a singleExtensions, by 
defining an extension. 

Denis 

> Thinking laterally on this issue. 
> 
> The issue here seems to come up with the problem that OCSP does not 
> have a proper response code for 'does not exist', Now let us imagine
> for a moment that we borrow from the prior art in DNSSEC and have an
> NSEC3 type capability that provides a status for the 'gaps' between 
> certificates. Wouldn't this meet all the essential use cases? 
> 
> The gaps could be specified either as gaps between certificate 
> serial numbers or gaps between cert hashes. I would like to see an 
> OCSP extension to allow the hash of the cert to be specified in any 
case. 
> 
> So the old style OCSP token is (essentially) 
> 
>    Sign (key, { {status-value, issuer, serial, {extensions}} } ) 
> 
> I would like to change that for certs that exist to: 
> 
>    Sign (key, { {status-value, issuer, serial, {certhash, extensions}} } 
) 
> 
> And if there is a query for a cert that does not exist and the 
> request indicates that you can process it, you would get back: 
> 
>    Sign (key, { {non-existent, issuer, dummy-serial, {{start-
> indicator, end-indicator}, extensions}} } ) 
> 
> This type of response would only ever be returned in an OCSP query 
> response. There would be no point whatsoever in stapling a non-
> existent OCSP token to a TLS cert chain (OK not unless you were an 
> attacker and you knew it would cause the chain to break somehow, but
> we design it to avoid that happening) 
> 
> It might be desirable to obfusticate the start and end indicators 
> somewhat to prevent cert population walking. But I rather doubt we 
> would end up hiding any information that can't be got using stats.  
> 
> This has been in the DNSSEC spec for over a decade so it is almost 
> certainly unencumbered. It allows us to provide a signed response to
> every OCSP query from static data. So why didn't we think of doing 
> it from the start? 
> 
> The only (minor) issue is that if there is a cert issued AFTER the 
> date of the OCSP token, the negative response token becomes invalid.
> Although that turns out to be a moot point as if someone can hand 
> you the negative response token in response to the OCSP request, 
> they can stop you getting the valid OCSP token so you are hosed anyway.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 7 Nov 2011 14:00:43 +0000

Since a Responder desiring whitelist functions need only respond "Revoked"
for certificates for which is has no positive record, I see no reason to
introduce a new extension to a standards-track protocol.

Also, RFCs do not mandate implementation timelines.

-- T

On 11/7/11 3:06 AM, "[email-masked]" <[email-masked]> wrote:

>In order to take advantage of OCSP responders
>which would be able to use white lists of certificates,
>This new single extension SHOULD be
>supported as soon as the responder uses white lists of certificates
>( I would even say "SHALL  be supported within 2 years from now"
>to allow a smooth migration).
>
>This single extension would indicate
>something like "cert. status checked using white lists".
>
>Although not mandatory, this new extension
>could also include the hash value of the certificate computed
>In order to illustrate the difference
>of behavior between an OCSP responder using CRLs and
>another one using white lists of certificates in case the query is about
>a certificate which has never been issued.
>
>singleExtension
>"cert. status checked using white lists" present.
>
>
>A :      
>Date :      
> 27/10/2011 10:22
>Objet :    
>   Re: [pkix] An
>alternative proposal Was: Fwd: New Version Notification
> for draft-hamilton-cmr-00.txt
>Envoyé par :    
>   [email-masked]
>________________________________________
>
>
>
>Phil, 
>
>We both agree that the problem comes from
>the fact that OCSP does not have a proper response code for 'does not
>exist';
>
>I would simply propose that we advertise this in a singleExtensions,
>by defining an extension.
>
>Denis 
>
> 
>>    Sign (key, { {status-value, issuer, serial, {certhash,
>extensions}} } ) 
>> 
>>https://www.ietf.org/mailman/listinfo/pkix_______________________________
>>________________
>pkix mailing list
>[email-masked]

---

From: Rob Stradling <[email-masked]>
Date: Mon, 7 Nov 2011 14:34:17 +0000

On Monday 07 Nov 2011 14:00:43 Miller, Timothy J. wrote:
> Since a Responder desiring whitelist functions

But what if the OCSP Client wants to know that there is "no positive record" 
of the certificate's existence?

> need only respond "Revoked" for certificates for which is has no positive
> record,

This would be problematic for Responders that only use pre-generated 
Responses.  However, if such a Responder has access to the CA's database, it 
would be able to include a "cert. status checked using white lists" indicator 
and/or a hash of the certificate in a new singleExtension in the Response.

Are we trying to concoct a mechanism to prove the existence of a cert?  Or to 
prove the non-existence of a cert?  Or both?  Or either?

> I see no reason to introduce a new extension to a standards-track
> protocol.
<snip>

Rob Stradling

---

From: Peter Sylvester <[email-masked]>
Date: Mon, 07 Nov 2011 13:17:14 +0100

On 11/07/2011 10:06 AM, [email-masked] wrote:
> singleExtension"cert. status checked using white lists" present.
Such an extension is not really necessary IMO. If you have a white list, you
respond good only to the good ones, and revoked to anything else
(in you realm), i.e.,  unknown,  when one asks you a question about a CA
that you don't handle. One can also use a revocation date of last 
century etc.

For the good case, one may add a fingerprint in the response, ... and
for the revoked case also, if it was on the white list.

I am not sure whether there is RP software that implies existence
of a cert when an OCSP responder returns revoked. ;-)

So what remains to define, is an extension that returns some representation
of an existing which is "better" that just a serial number.
A client sending a fingerprint seems better to me.

I vaguely remember that the last draft before RFC still had the
possibility that a client could send a certificate to the server, an
option which was silently dropped.

---

From: "Kyle Hamilton" <[email-masked]>
Date: Mon, 7 Nov 2011 10:39:50 -0800 (Pacific Standard Time)

On Thu, Nov 3, 2011 at 6:51 AM, Kemp, David P. <[email-masked]> wrote:
> on.

I disagree.

If the logs are deleted, then the whitelist would still serve as a record of what the CA believes the legitimately-issued certificates are supposed to be.  By doing so, the unlogged certifications would not be on the list and so would fail validation.

>  Given the lack of even rudimentary availability controls, what

What makes you think that we (consumers and businesses) should expect CAs to perform anywhere near the level we're currently demanding of them?  They do not dictate terms to us, they do not have any legitimate right to restrict what we do or how we interact with anyone else, and we shouldn't be trusting them or giving them any power more than the absolute minimum of "the CA states and provides OCSP to the effect that this certificate and the subject it was issued to are properly recorded in its files."

We do not dictate terms to them, we have no legitimate right to restrict what they do or how they interact with anyone else, and they certainly don't trust anything we say, only the documents we provide.  For lack of any better term, we are equals to them.  We have the right and responsibility to use their services for what they're good for -- and not for what they're not good for.

So, a whitelist works to permit the CA to essentially separately confirm the certificate, transferring the countersignature separately (through a different channel) from the actual data structure which encodes the certified information.  In this model, the signature on the certificate acts as an integrity mechanism (the equivalent of a CRC) more than an authentication mechanism.

-Kyle H

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 7 Nov 2011 18:57:27 +0000

>of the certificate's existence?

It can ask my shoe size while it's at it, that doesn't mean it needs a
response.  

>Responses.  

If the Responder is using pre-signed responses the Responder can't answer
because it can't sign the response.  You can't do pre-signing in this mode
because the set of non-existing certificates is infinite.

If the Responder *can* sign the response, why is it using pre-signed
responses?

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Mon, 7 Nov 2011 19:10:01 +0000

On 11/7/11 12:39 PM, "Kyle Hamilton" <[email-masked]> wrote:

>If the logs are deleted, then the whitelist would still serve as a record
>of what the CA believes the legitimately-issued certificates are supposed
>to be.  By doing so, the unlogged certifications would not be on the list
>and so would fail validation.

If the CA records (e.g., logs) are corrupt, where exactly does the
whitelist come from?  God?

>[...] They do not dictate terms to us, [...] We do not dictate terms to
>them, 

It's called a contract.

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 7 Nov 2011 15:00:15 -0500

As an individual consumer, I have no right to dictate how Ford Motor Corporation builds cars.  But I do have the right to not buy a used Pinto after seeing exploding gas tanks on TV.  Fleet consumers (e.g. police departments) have more leverage to request production changes, but still no right to dictate.

I would choose not to trust a CA that cannot determine what certificates it has issued after being attacked by hacker or hurricane.  "Properly recorded in the files it has on hand" is a pretty low bar, and before granting access to valuable private information based on a cert, I'd set the bar a little higher.  I fully realize that the CA has no legal obligation to respond to my lack of faith.

Dave

-----Original Message-----
From: Kyle Hamilton [mailto:[email-masked]] 
Sent: Monday, November 07, 2011 1:40 PM
To: Kemp, David P.
Cc: Rob Stradling; [email-masked]
Subject: Re: [pkix] An alternative proposal Was: Fwd: New VersionNotification for draft-hamilton-cmr-00.txt

I disagree.

-Kyle H

---

From: Rob Stradling <[email-masked]>
Date: Tue, 8 Nov 2011 12:04:50 +0000

> It can ask my shoe size while it's at it, that doesn't mean it needs a

Are you suggesting that OCSP Clients have absolutely no right to know whether 
or not a given serial number belongs to an existing certificate?

> because the set of non-existing certificates is infinite.

Exactly my point.  However, if the code that pre-signs the Responses has 
access to the CA's database, the pre-signed Responses could include a new 
singleExtension with a hash of the certificate.  This would indicate a positive 
record of the cert's existence to OCSP Clients.

> If the Responder *can* sign the response, why is it using pre-signed

It most likely wouldn't be.

Rob Stradling

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 8 Nov 2011 13:22:50 +0000

>or not a given serial number belongs to an existing certificate?

How can I say this more clearly?

If you can't trust the CA to know what it has issued and what it hasn't,
you can't create a trustable whitelist.  If you can trust the CA to know
what it has issued and what it hasn't, you don't need a whitelist.

Period.  

End of concept.

Did I miss anything?

>record of the cert's existence to OCSP Clients.

My fraudulent cert is in the damn database, so a response gets generated.
What was the goal again?

-- T

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Nov 2011 16:11:11 -0500

> what it has issued and what it hasn't, you don't need a whitelist.

Are we talking here about audited public CAs or CAs in general?

Private CAs have always been able to screw up in interesting and novel
ways, many of them have. Such failures don't attract notice, maybe they
should have.

A system with a single point of failure may be appropriate for your
application. But that has never been the approach to design of commercial
public CAs, at least not for the ones I have been involved with.

A control for a situation that should never occur? Of course! KGB doctrine
was always that there be two separate systems with completely independent
operational principles that were each independently capable of providing
complete security.

The proposal to have an extension for 'there really is a cert with this
serial' seems a no brainer to me. It is 100% compatible with the deployed
base. If your systems can't generate it and you don't want it then fine.
But I don't see how we approach our risk control should matter to you.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 8 Nov 2011 22:04:21 +0000

>But I don't see how we approach our risk control should matter to you.

Let me ask this another way.  Given the following responses from a
putative whitelist-based OSCP responder:

1. good
2. good + whitelist info
3. revoked
4. revoked + whitelist info
5. unknown
6. unknown + whitelist info

How do you expect a client to process and act on each of these responses?
Is the relying application supposed to treat (1) as good and (2) as
double-plus-good?  Similarly is (3) more or less invalid than (4)?  Is (5)
more or less unknown than (6)?  How do these distinctions matter in
practice?

-- T

---

From: Martin Rex <[email-masked]>
Date: Wed, 9 Nov 2011 00:34:24 +0100 (MET)

> 6. unknown + whitelist info

While the classification  good / revoked / unknown is what rfc2560
acutally defines, this is purposefully misleading terminology.

The orginal OCSP does contain "good", all it has is

"not known to be be bad (based on the revocation info that I've checked
 and the assumption that I should know)".

I would expect the "whitelist" to not contain any revoked certs,
in which (4) does not exist, and I believe (6) does not make any sense.

> double-plus-good?

That is a problem that current TLS clients seem to have solved already
(those that request OCSP but do not hard fail if they can not obtain
 an OCSP response).

>
> How do these distinctions matter in practice?

They can help to reduce the risk from hash collisions with
older signatures (and potially weak signature algorithms)
of a CA key that is still in use (i.e. a "tainted" key).

e.g. http://www.win.tue.nl/hashclash/rogue-ca/

If the OCSP responder would be returning a hash of the originally
issued certificate (with a stronger hash algorithm, of course)
from a whitelist, then you have less problems with "tainted"
CA keys.

Personally, I consider all RootCA certs with a 2048-bit or larger
RSA key and SHA-1 for the self-signed signature a "tainted" keypair.

-Martin

---

From: Tom Ritter <[email-masked]>
Date: Tue, 8 Nov 2011 19:48:55 -0500

> more or less unknown than (6)?  How do these distinctions matter in

Browsers have successfully distinguished between EV and non-EV certs.
Some people actually do make trust decisions based on calculated trust
via the Web of Trust, and 'somewhat trusting' certain signatures.  You
can download and run an executable on Windows with or without a
Publisher signature.  But they all afford greater trust to one path,
and less trust to the other (while still allowing the action).  If a
browser makes the decision to expose an indicator of greater trust to
a whitelisting OCSP server (which I agree with) - organizations that
care will seek out that indicator.

> what it has issued and what it hasn't, you don't need a whitelist.

This assumes the OCSP database is populated automatically.  Just as an
auditor should flag a deployment that accepts client certificates but
doesn't validate them (as adding no security), so too should an
auditor flag such an OCSP deployment.  I agree - it would be useless.
It should be deployed such that it is another barrier for an attacker
to overcome.

I support OCSP responders acting on whitelists instead of blacklists,
and would like a way in the protocol to know whether a responder is
acting based off that or not - rather than knowing by reading audit
reports I may or not even be able to access.

-tom

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 9 Nov 2011 09:56:06 -0500

Tom,

Technical mechanisms don't exist in a vacuum, they exist to support
business processes.  The business process of a CA (as described in its
CPS) is to know its subscribers and convey information about them to
RPs.  Technical mechanisms (certs, whitelists, blacklists) aren't a CA's
business, they merely convey information the CA has obtained through
conducting its business.  As an analogy, Gartner Group does not exist to
produce PDF files, it's business is market analysis.  PDF and HTML are
just mechanisms used to convey that information.

A whitelist is not another barrier for an attacker to overcome, it is
the same barrier as a blacklist because it reflects (a different view
of) the same business information.  I'm not sure why you think manual
population is more reliable than automatic population, but assuming
that's true, manual population of a blacklist from all information known
to the CA is no more or less reliable than manual population of a
whitelist from the identical information.  If the CA's information has
been corrupted by intentional or natural events, neither blacklist nor
whitelist can make the transmitted information more reliable than it was
prior to transmission.

If the CA's information is corrupted to the point where it cannot figure
out who its subscribers are and what certs it has issued, then the CA
should reset its operations, declare a "recovered" date, rekey the CA,
and revoke the previous CA key.  At that point a blacklist would start
empty and a whitelist would include all certs issued after the recovery
date.  The same bandwidth/efficiency arguments for using black or white
lists exist as always, but there is no valid argument that whitelists
provide an "additional barrier" to attackers.

A CA that discovered that its operations had been compromised but chose
to continue signing certificates using the same key as used during the
period of compromise is only providing additional evidence that it is
not worthy of trust.

Dave

-----Original Message-----
Tom Ritter

> If you can't trust the CA to know what it has issued and what it 
> hasn't, you can't create a trustable whitelist.  If you can trust the 
> CA to know what it has issued and what it hasn't, you don't need a
whitelist.

This assumes the OCSP database is populated automatically.  Just as an
auditor should flag a deployment that accepts client certificates but
doesn't validate them (as adding no security), so too should an auditor
flag such an OCSP deployment.  I agree - it would be useless.
It should be deployed such that it is another barrier for an attacker to
overcome.

---

From: [email-masked]
Date: Wed, 9 Nov 2011 16:15:37 +0100

David,

You said:

"A CA that discovered that its operations had been compromised but chose
to continue signing certificates using the same key as used during the
period of compromise is only providing additional evidence that it is
not worthy of trust".

I believe you meant:

"A CA that discovered it cannot figure the exact extend of the damages but 
chose
to continue signing certificates using the same key as used during the
period of compromise is only providing additional evidence that it is
not worthy of trust".

 ... but we are far away from the original question:

Do you believe that it is worthwhile to define this new extension ?

Denis

De :    "Kemp, David P." <[email-masked]>
A :     <[email-masked]>
Date :  09/11/2011 15:56
Objet : Re: [pkix] Proposed new singleExtension for OCSP
Envoyé par :    [email-masked]

Tom,

Dave

-----Original Message-----

whitelist.

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 9 Nov 2011 15:47:27 -0000

Isn't it true though that a white-list check would help the CA to detect the
problem?  I.e. there is a fake certificate out there which is being used (I
agree this assumes that an attacker managed to get a fake certificate
somehow and not injected it into the CA's database - maybe I am wrong but I
believe this was the case for DigiNotar). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Kemp, David P.
Sent: 09 November 2011 14:56
To: [email-masked]
Subject: Re: [pkix] Proposed new singleExtension for OCSP

Tom,

Technical mechanisms don't exist in a vacuum, they exist to support business
processes.  The business process of a CA (as described in its
CPS) is to know its subscribers and convey information about them to RPs.
Technical mechanisms (certs, whitelists, blacklists) aren't a CA's business,
they merely convey information the CA has obtained through conducting its
business.  As an analogy, Gartner Group does not exist to produce PDF files,
it's business is market analysis.  PDF and HTML are just mechanisms used to
convey that information.

A whitelist is not another barrier for an attacker to overcome, it is the
same barrier as a blacklist because it reflects (a different view
of) the same business information.  I'm not sure why you think manual
population is more reliable than automatic population, but assuming that's
true, manual population of a blacklist from all information known to the CA
is no more or less reliable than manual population of a whitelist from the
identical information.  If the CA's information has been corrupted by
intentional or natural events, neither blacklist nor whitelist can make the
transmitted information more reliable than it was prior to transmission.

If the CA's information is corrupted to the point where it cannot figure out
who its subscribers are and what certs it has issued, then the CA should
reset its operations, declare a "recovered" date, rekey the CA, and revoke
the previous CA key.  At that point a blacklist would start empty and a
whitelist would include all certs issued after the recovery date.  The same
bandwidth/efficiency arguments for using black or white lists exist as
always, but there is no valid argument that whitelists provide an
"additional barrier" to attackers.

A CA that discovered that its operations had been compromised but chose to
continue signing certificates using the same key as used during the period
of compromise is only providing additional evidence that it is not worthy of
trust.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom
Ritter

whitelist.

This assumes the OCSP database is populated automatically.  Just as an
auditor should flag a deployment that accepts client certificates but
doesn't validate them (as adding no security), so too should an auditor flag
such an OCSP deployment.  I agree - it would be useless.
It should be deployed such that it is another barrier for an attacker to
overcome.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 9 Nov 2011 08:25:09 -0800

On Nov 9, 2011, at 7:47 AM, Liaquat Khan wrote:

> problem?  

That would be an *internal* mechanism, not the externally-visible mechanism that started this thread.

--Paul Hoffman

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 9 Nov 2011 19:05:39 +0000

>believe this was the case for DigiNotar).

This depends what you mean by fake.  If it's just a name collision, the
cert won't chain and you don't need the whitelist.  If it was fraudulently
issued, it only matters in the single case where the CA record of that
cert is destroyed.

-- T

---

From: Tom Gindin <[email-masked]>
Date: Wed, 9 Nov 2011 20:52:16 -0500

There are three parties interested in the revocation status of a 
certificate - CA, subscriber and RP.  For public CA's, the RP is not 
normally a party to the contract between the CA and the subscriber.  Since 
revocation checking involves an interaction between the RP and a provider 
chosen by the CA, contracts may not help.

                Tom Gindin

From:   "Miller, Timothy J." <[email-masked]>
To:     Kyle Hamilton <[email-masked]>, "Kemp, David P." 
<[email-masked]>, 
Cc:     "[email-masked]" <[email-masked]>
Date:   11/07/2011 02:11 PM
Subject:        Re: [pkix] An alternative proposal Was: Fwd: New 
VersionNotification for draft-hamilton-cmr-00.txt
Sent by:        [email-masked]

It's called a contract.

-- T

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 10 Nov 2011 16:05:22 +0100

> That would be an *internal* mechanism, not the externally-visible mechanism that started this thread.

This remark sounds like "believe us, we have our *internal*' measure, 
you might
want to audit them, but ...".

A data format that allows a CA server to make a snapshot to be stored in an
electronic safe doesn't seem to me a useless thing.  A standardized format
simplifies reversability and auditing.

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 10 Nov 2011 11:57:33 -0500

As far as detecting "magically appearing" certs goes, there are many
possible mechanisms:

1) CA exposes a view of its database to non-CA-operated responders, just
as it would to CA-operated responders
2) Responder queries CA for database status before generating response
3) Responder informs CA of cert query but doesn't expect a response
4) Responder generates a list of certs queried in the last N minutes and
forwards it to the CA

None of these require an OCSP extension.

If RPs really care about this, the CA's CPS could contain a clause
saying:

"To protect against the possibility that some attacker could use our
private key without our knowledge to sign bogus certificates, all status
responders are required as a condition of operation to inform us of all
certificates queried within xxx hours."

Yes, the RP would have to trust that compliance with the CPS is audited.
Do you know of any RPs that care to do more for this specific bizarre
use case while being satisfied with auditing the many more important
things that happen every day?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Sylvester
Sent: Thursday, November 10, 2011 10:05 AM
To: [email-masked]
Subject: Re: [pkix] Proposed new singleExtension for OCSP

On 11/09/2011 05:25 PM, Paul Hoffman wrote:
>> Isn't it true though that a white-list check would help the CA to 
>> detect the problem?

This remark sounds like "believe us, we have our *internal*' measure,
you might want to audit them, but ...".

A data format that allows a CA server to make a snapshot to be stored in
an electronic safe doesn't seem to me a useless thing.  A standardized
format simplifies reversability and auditing.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 10 Nov 2011 18:05:37 +0100

Did I mention OCSP. It seems that there are in fact two discussions in 
this thread.

   client-"notary"
   "notary"-CA