Re: [lamps] Revocation Request Format?

[Ryan Sleevi <[e-mail]>]

On Fri, Mar 2, 2018 at 4:45 PM, Stephen Farrell <[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).