Re: [lamps] Revocation Request Format?

[Tim Hollebeek <[e-mail]>]

I agree with Ryan.

 

Some standardized methods of proof of compromise would be useful for typical compromise scenarios (I hope Ryan agrees with that), but you can’t produce an exhaustive list of what’s acceptable.

 

We’re not going to be able to standardize “I have a quantum computer in my back pocket, here’s how I demonstrate that” or “if I wiggle my fingers at the public key like so, the private key appears in an thought bubble above its head”.

 

Security failures happen when assumptions and abstract models break down.  If you can demonstrate that you can violate those assumptions, people have to be prepared to deal with the consequences.

 

-Tim

 

From: Spasm [mailto:[e-mail]] On Behalf Of Ryan Sleevi
Sent: Friday, March 2, 2018 3:34 PM
To: Stephen Farrell <[e-mail]>
Cc: Ryan Sleevi <[e-mail]>; SPASM <[e-mail]>; Phillip Hallam-Baker <[e-mail]>; Peter Bowen <[e-mail]>
Subject: Re: [lamps] Revocation Request Format?

 

 

 

On Fri, Mar 2, 2018 at 4:45 PM, Stephen Farrell <[e-mail] <mailto:[e-mail]> > wrote:



On 02/03/18 21:19, Ryan Sleevi wrote:
> Because it's a demonstration of compromise. Any attempt to define how that
> demonstration of compromise is proved (which I think is *bad*
> standardization) is to make it more difficult to report or demonstrate
> compromise.

I don't understand the "any" in the above.

Can you clarify?

 

So, there's two scenarios for key compromise that we're considering in the CA space

1) I have the private key (Heartbleed, Trustico, rooted servers, etc)

2) I have a signing oracle (Bleichenbacher, ROBOT, etc)

  a) Note: The signing oracle may be somewhat constrained in message formatting, but still provides an oracle sufficient to count as compromise

  b) Note: The signing oracle may be temporary in nature, so I'd be particularly concerned with systems that require nonces or timestamps, as they would incentivize disclosure to the CA first, rather than to the 'presumed legitimate' keyholder.

 

Further, we have at least several actors to consider demonstration of compromise to:

I) The CA/issuer

II) Those that oversee the trust anchor management that includes the CA

III) The public

 

Because 2) exists, and the constraints re: 2 a), we need ecosystem flexibility for how we demonstrate proof. That is, it will be somewhere along a spectrum, based on what I, II, III find an acceptable demonstration. I might want to require a challenge, but II does not, for example.

 

Thus, because the ecosystem has flexibility, 1) can easily adapt to whatever is needed - because they have the key, they are technically capable of producing any signed message necessary for I, II, III - of which we already have plenty of ways of expressing, whether it be raw signatures, CSRs, SPKACs, whatever your heart desires. There's no need to invent a new format, because we have infinitely flexible formats already available, and because the policy for I, II, and III will be inherently variable anyways.

 

Further, I am deeply concerned for situations in which 1) - or any standardized version of expressing that - is seen as the only form of compromise or the only acceptable form of demonstrating that. This isn't hypothetical - this is a problem that, in acting in the role of a browser trust store maintainer (II), I've had to chase down a number of CAs (I), because they only want to revoke for 1) (... if even that). That's a policy matter, for sure, but it's a policy matter that I fear is or would be amplified.

 

So I think attempts at 1) are somewhere along the line of https://xkcd.com/927/ , where we already have a number of methods.

 

But let's go further, and imagine that let's say we wanted to have an interoperable definition for proof-of-key-compromise, so that you don't see what we see today - where CA Foo revokes a certificate as compromised, and the Subscriber then goes to CA Bar and requests a new certificate - with the same key. It might seem appealing to suggest that an interoperable proof of compromise would facilitate that information sharing, perhaps via some shared transparent ledger. And I totally get that appeal, but that's only addressing 1), and not 2), so we're not really addressing 'compromise' in the broad sense, just 'compromise' in the narrow sense - and we're just adding more work for those who do have the key to adopt whatever the new hotness is, creating ecosystem adoption issues.

 

That's why I think an effort to standardize there is bad, not good, because it counterintuitively fragments the ecosystem, without addressing the general issue, which is in my view is moreso a matter of policy, because of the inherent constraints of 2).