Subject: [lamps] Revocation Request Format?

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 2 Mar 2018 09:24:05 -0500

Do we have a PKIX revocation request format?

I am asking because of a detail in the Trustico situation in which a file
of 23K private keys was emailed to a CA to request revocation.

At the point, the circumstances of that situation are not clear. But I can
see a scenario in which it is entirely plausible that a CA reseller would
have access to large numbers of TLS private keys and that is when they are
either hosting or managing the Web sites.

The management interfaces that allow Web sites to be wheeled around a data
center have become very sophisticated of late with virtualization and much
of that infrastructure is 'secret sauce'.

What might appear to be a five racks of 100 separate machines is likely
visible in the management console as one single entity.

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 2 Mar 2018 11:08:10 -0500

It seems signing a new CSR has been a common practice as proof of
possession.

There's one segment of users that want to have a time-constrained request
(that is, incorporating a challenge/response), while another would prefer
that you can generate the 'request to revoke' at the same time you request
the cert, so that you can use this token for situations such as loss of
private key (but not loss of revocation token)

It doesn't seem like there needs to be a bespoke format here, considering
that the industry is still working through its use cases, and any signed
data is sufficient.

Further, it may do harm to try and standardize that. Consider the ROBOT
attack ( https://robotattack.org/ ), which presented a signing oracle with
TLS private keys. Prematurely constraining revocation requests to a
particular format might otherwise preclude reasonable demonstration of
private key compromise.

So I don't think there's anything for LAMPS to do here - we have ample
available technology (running code that already works) and we have not yet
ascertained industry needs in any meaningful way (no rough consensus for
something new)

On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker <[email-masked]>
wrote:

> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm
>
>

---

From: Peter Bowen <[email-masked]>
Date: Fri, 2 Mar 2018 12:03:29 -0800

> ascertained industry needs in any meaningful way (no rough consensus for

There is also a documented (albeit not in RFCs) format for a generic
signed public key with challenge:
https://www.w3.org/TR/html51/sec-forms.html#the-keygen-element

PublicKeyAndChallenge ::= SEQUENCE {
  spki SubjectPublicKeyInfo,
  challenge IA5STRING
}

SignedPublicKeyAndChallenge ::= SEQUENCE {
  publicKeyAndChallenge PublicKeyAndChallenge,
  signatureAlgorithm AlgorithmIdentifier,
  signature BIT STRING
}

The challenge is an arbitrary length IA5STRING, so it could easily
include nonce or other challenge data to prove key control.

Thanks,
Peter

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 2 Mar 2018 15:17:03 -0500

If it is a signing key, just sign a CRL for the certificate. Now that is
not quite the same as revoking the key but certs are the only things PKIX
makes status assertions about.

Do we have to support self-revocation of certs with only encryption only
keys? Probably not.

Since a very common reason for having to revoke a cert is that the private
key is lost entirely any revocation format cannot be the only way to
request revocation. So I don't see the relevance of the robot attack.

Standards are all about taking choices that don't matter except that a
choice is made. If we choose to recognize CRL suicide notes as the one
mechanism that must be supported, that is one mechanism that can be added
to PKI toolkits that don't already have it. And yes, there is at least one
widely used toolkit that allows certificates and CRLs to be parsed but not
generated.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 2 Mar 2018 12:26:10 -0800

ACME already specifies how to revoke by proving control of the private
key, or by proving control of the affected domains. If a CA wants to
provide standards-based revocation services, they don't need to
implement all of ACME, just enough to sign up for an account and do the
revocation request.

On 03/02/2018 12:17 PM, Phillip Hallam-Baker wrote:
> If it is a signing key, just sign a CRL for the certificate. Now that
> is not quite the same as revoking the key but certs are the only
> things PKIX makes status assertions about.
>
> Do we have to support self-revocation of certs with only encryption
> only keys? Probably not.
>
> Since a very common reason for having to revoke a cert is that the
> private key is lost entirely any revocation format cannot be the only
> way to request revocation. So I don't see the relevance of the robot
> attack.
>
>
> mechanism that must be supported, that is one mechanism that can be
> added to PKI toolkits that don't already have it. And yes, there is at
> least one widely used toolkit that allows certificates and CRLs to be
> parsed but not generated.
>
>
>
> On Fri, Mar 2, 2018 at 3:03 PM, Peter Bowen <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Fri, Mar 2, 2018 at 8:08 AM, Ryan Sleevi <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     <https://www.w3.org/TR/html51/sec-forms.html#the-keygen-element>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 2 Mar 2018 16:19:31 -0500

> request revocation. So I don't see the relevance of the robot attack.

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.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 2 Mar 2018 21:45:55 +0000

> standardization) is to make it more difficult to report or demonstrate

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

Can you clarify?

Ta,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 2 Mar 2018 17:08:19 -0500

Hmmm...

Well ACME is intended to be a comprehensive certificate lifecycle protocol.
I guess it might depend on whether that part needed JSON or just ASN.1...

Might be all we would need to do is to add a page or two calling out
standalone use as a specific use case and declare victory.

On Fri, Mar 2, 2018 at 3:26 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> provide standards-based revocation services, they don't need to implement
> all of ACME, just enough to sign up for an account and do the revocation
> request.
>
>
> Spasm mailing [email-masked]://www.ietf.org/mailman/listinfo/spasm
>
>
>

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 2 Mar 2018 17:33:36 -0500

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

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).

---

From: Tim Hollebeek <[email-masked]>
Date: Fri, 2 Mar 2018 23:57:02 +0000

One thing I would consider doing if I found myself in this situation is to take a fresh, signed OCSP response along with some text like REVOKE THIS CERTIFICATE and sign it with the private key for the certificate in question.

Haven’t done a full security analysis of the pros/cons but I thought I’d throw it out there.  It has some nice information about exactly which certificate and exactly when I made the request, and that it was made by someone with access to the private key.

It seems like a better idea than abusing a CSR for an unintended purpose.  Abusing signed messages for purposes they weren’t designed for usually ends badly.

-Tim

From: Spasm [mailto:[email-masked]] On Behalf Of Ryan Sleevi
Sent: Friday, March 2, 2018 9:08 AM
To: Phillip Hallam-Baker <[email-masked]>
Cc: SPASM <[email-masked]>
Subject: Re: [lamps] Revocation Request Format?

It seems signing a new CSR has been a common practice as proof of possession.

There's one segment of users that want to have a time-constrained request (that is, incorporating a challenge/response), while another would prefer that you can generate the 'request to revoke' at the same time you request the cert, so that you can use this token for situations such as loss of private key (but not loss of revocation token)

It doesn't seem like there needs to be a bespoke format here, considering that the industry is still working through its use cases, and any signed data is sufficient.

Further, it may do harm to try and standardize that. Consider the ROBOT attack ( https://robotattack.org/ ), which presented a signing oracle with TLS private keys. Prematurely constraining revocation requests to a particular format might otherwise preclude reasonable demonstration of private key compromise.

So I don't think there's anything for LAMPS to do here - we have ample available technology (running code that already works) and we have not yet ascertained industry needs in any meaningful way (no rough consensus for something new)

On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]> > wrote:

I am asking because of a detail in the Trustico situation in which a file of 23K private keys was emailed to a CA to request revocation.

At the point, the circumstances of that situation are not clear. But I can see a scenario in which it is entirely plausible that a CA reseller would have access to large numbers of TLS private keys and that is when they are either hosting or managing the Web sites.

The management interfaces that allow Web sites to be wheeled around a data center have become very sophisticated of late with virtualization and much of that infrastructure is 'secret sauce'.

What might appear to be a five racks of 100 separate machines is likely visible in the management console as one single entity.

_______________________________________________
Spasm mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/spasm

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 2 Mar 2018 19:45:55 -0500

On Fri, Mar 2, 2018 at 6:57 PM, Tim Hollebeek <[email-masked]>
wrote:

> One thing I would consider doing if I found myself in this situation is to
> take a fresh, signed OCSP response along with some text like REVOKE THIS
> CERTIFICATE and sign it with the private key for the certificate in
> question.
>
>
>
> Haven’t done a full security analysis of the pros/cons but I thought I’d
> throw it out there.  It has some nice information about exactly which
> certificate and exactly when I made the request, and that it was made by
> someone with access to the private key.
>

Right, and I'm actually arguing against those properties as being
reasonable, for reasons I expand on bleow.

> It seems like a better idea than abusing a CSR for an unintended purpose.
> Abusing signed messages for purposes they weren’t designed for usually ends
> badly.
>

The key is compromised. It's already ended badly. The format won't change
that if it is compromise, and since only the key holder can produce signed
messages in the first place, if they're signing a message that says their
key is compromised, well, then we know the just self-compromised :)

Perhaps the distinction is whether it's a Subscriber-initiated request or a
Third-Party initiated request.

For a Subscriber initiated request, there's no inherent requirement to
require they demonstrate the private key. It's fundamentally a question
about certificate lifecycle management, and one could just as easily
imagine a 'revoke this cert' button in the subscriber's certificate
management portal. Formats here don't help the subscriber, because the
revocation is part of the lifecycle management, and that overall process is
where you want to see the alignment. For a CA that supports ACME for
lifecycle management, ACME addresses this. However, for a CA that doesn't
use ACME, or a Subscriber who doesn't use ACME, the ACME lifecycle
management is more onerous and detrimental, and out of sync with the rest
of the lifecycle management.

For a third-party initiated request - that is, security researcher or the
like - I don't think more formats is necessarily beneficial. The burden
lies on the CA, not the reporter, regarding the investigation and handling
of this. Properties such as "Was this freshly done" are actively
detrimental, rather than beneficial - if it was compromised in the past,
then that's reasonable grounds for revocation. As for aligning how to
identify the certificate, that benefits the CA, sure, but it doesn't
benefit the reporter. If anything, it adds more burden on the reporter to
now try and shape their proof in a way the CA will accept.

>From a policy point of view, the policies on what an acceptable form of
proof is will vary based on the PKI. For the Web PKI, *any* proof of a
signed message, I would argue, is sufficient proof, so there's no need to
introduce formats for reporting, because any signed message is sufficient,
and, at a minimum, CAs are required to be monitoring that 24/7 with real
people and responding within 24 hours. So, at best, we're talking
optimizing the speed at which a CA responds by offering additional methods
for providing demonstration, but they aren't replacement methods nor will
they be sufficient methods. Nor are they necessarily optimizations - while
it may enable the CA to respond more quickly, it doesn't guarantee they
will - that's a question of policy for that particular PKI, and at least in
the Web PKI, CAs have the flexibility for 24 hours for investigation, 24
hours for revocation, and 24 hours for publication, and the incentive
structure is very much aligned for CAs to take advantage of that full time
precisely because it serves as a risk management method for them.

>
>
> -Tim
>
>
>
> *From:* Spasm [mailto:[email-masked]] *On Behalf Of *Ryan Sleevi
> *Sent:* Friday, March 2, 2018 9:08 AM
> *To:* Phillip Hallam-Baker <[email-masked]>
> *Cc:* SPASM <[email-masked]>
> *Subject:* Re: [lamps] Revocation Request Format?
>
>
>
> attack ( https://robotattack.org/ ), which presented a signing oracle
> with TLS private keys. Prematurely constraining revocation requests to a
> On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker <
> [email-masked]> wrote:
>

---

From: Tim Hollebeek <[email-masked]>
Date: Sat, 3 Mar 2018 04:17:28 +0000

Right.  If there is an assertion that public key X is bound to Ryan Sleevi, 
and I, as an individual who is provably not Ryan Sleevi [1], can successfully 
sign anything as Ryan Sleevi, revocation is required.

We need to make sure that any revocation rules and policies that exist respect 
that principle.

-Tim

[1] How many people can actually prove that?  Other than Ryan?

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.

---

From: Tim Hollebeek <[email-masked]>
Date: Sat, 3 Mar 2018 04:28:03 +0000

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:[email-masked]] On Behalf Of Ryan Sleevi
Sent: Friday, March 2, 2018 3:34 PM
To: Stephen Farrell <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; SPASM <[email-masked]>; Phillip Hallam-Baker <[email-masked]>; Peter Bowen <[email-masked]>
Subject: Re: [lamps] Revocation Request Format?

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

Can you clarify?

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

  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

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).

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 3 Mar 2018 06:29:30 +0000

> the inherent constraints of 2).

FWIW, I don't agree with your conclusion that *any* standardisation
of revocation signals would be counter-productive, but I also don't
think we ought do any such standardisation unless there are a bunch
of CAs and writers of private key handling s/w who do in fact want
to use the same new format for revocation signalling. I don't see a
whole bunch of CAs and others wanting that right now.

So in the short term, I think we agree as to what to (not) do:-)

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 3 Mar 2018 12:07:59 -0500

> So in the short term, I think we agree as to what to (not) do:-)

​At this point, the incident that motivated this proposal happened 4 days
ago. So it would probably be a mistake to bang out a draft and promote it
to RFC.​

​What I was most interested to know is if we had done the work already and
the answer appears to be not in PKIX​ but possibly in ACME. It might just
be that all we need to do is to add a few paragraphs to ACME and maybe get
an IANA content type for whatever the standalone message blob is.

I do think we will need to standardize because we are almost certain to
want to pop these blobs in our CT logs at some point and it is in any case
the right thing to do. One code path is always better than five code paths
offering the same functionality.

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 03 Mar 2018 18:34:00 +0000

On Sat, Mar 3, 2018 at 12:07 PM Phillip Hallam-Baker <[email-masked]>
wrote:

> On Sat, Mar 3, 2018 at 1:29 AM, Stephen Farrell <[email-masked]
> > wrote:
>
>>
>>

It might be good to start with a Use Cases document first, to figure out
who the participants/constituents would be. This would align with Stephen’s
remark re: what writers of private key handling s/w should use. Considering
such solutions naturally preclude solving (some of) the “compromise”
scenarios that must be dealt with today, the merits of those use cases
could be independently evaluated before trying to shape such work.

I view the transparency aspect as similarly orthogonal - such transparency
is more beneficial for demonstrating the private key holder authorized a
revocation. In today’s Web PKI, that is a real problem with CAs
unilaterally revoking for specious reasons (“malware”, “customer stopped
paying monthly fee”, “we added a new domain name to the customer account”)
or Resellers, often misguided, requesting revocation per the terms of their
contract with the CA without regard to whether or not the Certificate
recipient desires it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 3 Mar 2018 22:24:10 -0500

On Sat, Mar 3, 2018 at 1:34 PM, Ryan Sleevi <[email-masked]> wrote:

>
> On Sat, Mar 3, 2018 at 12:07 PM Phillip Hallam-Baker <
>> On Sat, Mar 3, 2018 at 1:29 AM, Stephen Farrell <
>> [email-masked]> wrote:
>>
>>>
>>>
>> ​What I was most interested to know is if we had done the work already
>> and the answer appears to be not in PKIX​ but possibly in ACME. It might
>> just be that all we need to do is to add a few paragraphs to ACME and maybe
>> get an IANA content type for whatever the standalone message blob is.
>>
>>
​The customer's credit card having been declined due to fraud or a
chargeback for fraud is actually one of the most potent signs indicating
that the certificate is likely to be used maliciously.​

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 5 Mar 2018 09:31:14 +0000

I agree with this.  There’s no need to rush into anything as no buildings are currently burning down, but some of the things people are doing are slightly silly, and it would be worthwhile to come up with a set of potentially non-silly things, and look at the advantages/disadvantages of each.

It might be good to start with a Use Cases document first, to figure out who the participants/constituents would be. This would align with Stephen’s remark re: what writers of private key handling s/w should use. Considering such solutions naturally preclude solving (some of) the “compromise” scenarios that must be dealt with today, the merits of those use cases could be independently evaluated before trying to shape such work.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Mar 2018 10:49:37 +0000

Coupla minor notes below...

On 05/03/18 09:31, Tim Hollebeek wrote:
> I agree with this.  There’s no need to rush into anything as no
> buildings are currently burning down, but some of the things people
> are doing are slightly silly, and it would be worthwhile to come up
> with a set of potentially non-silly things, and look at the
> advantages/disadvantages of each.
> 
> 
> 
> It might be good to start with a Use Cases document first, to figure
> out who the participants/constituents would be. 

I'm not convinced that a use-cases document/draft would be useful,
just on the basis that, in the IETF context, those often tend to
produce text that ends up ignored (or OBE). But if someone has the
interest and cycles to write such text, then that's up to them and
maybe it'd be useful in this case, not sure. When it exists, I guess
I'd read it.

> This would align with
> Stephen’s remark re: what writers of private key handling s/w should
> use. 

I think s/should use/would use/ is more in line with what I meant to
say, both for CAs and those writing/using private key handling s/w.
Put another way, there's a lot of things we could say such folks
"should" do, but there's little point in doing so unless they would
actually do stuff.

Cheers,
S.

> Considering such solutions naturally preclude solving (some of)
> the “compromise” scenarios that must be dealt with today, the merits
> of those use cases could be independently evaluated before trying to
> shape such work.
> 
> 
> 
>

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 5 Mar 2018 13:49:56 +0000

> Put another way, there's a lot of things we could say such folks "should" 
> do, but
> there's little point in doing so unless they would actually do stuff.

I can state with high confidence that at least one CA would follow the best 
practices
in this area, once we actually figure out what they are ...

-Tim

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 5 Mar 2018 09:26:01 -0500

> maybe it'd be useful in this case, not sure. When it exists, I guess

Yeah, apologies, document was a bit to overloaded a term in the IETF sense
:) I meant that because this problem space is broad, and because the
original motivation (Trustico) isn't really addressed by
yet-another-format, in order to have discussion about the value of a
format, we should try to figure out what problem(s) trying to be addressed.

I tried to offer one ontology - revocation for non-compromise (certificate
lifecycle management), revocation for compromise by 1P (certificate
lifecycle management), revocation for compromise by 3P (incident
reporting). In that final category, I tried to distinguish types of
compromise (disclosure of private key vs signing oracle), and the policy
implications related to incident response. While the original framing was
posed as 1P, the facts available at the time of initial post identified it
was 3P - although the requestor in that incident viewed is as a revocation
request for non-compromise.

Identifying the problems trying to be solved would help identify whether
they are already addressed in other specs (e.g. ACME's definition of the
CLM interfaces), or whether there are unaddressed needs, and for what cases.

While I don't think that deserves formal publication, it does seem to
benefit from having a shared vocabulary for the problems - much like the
W3C WICG's notion of "Explainers" that try to define the problem and
demonstrate the solution, but are not themselves standardized - they're
just used to help ensure productive discussion of the spec.

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 Mar 2018 11:58:54 -0500

Phill:

PKCS#10 does not specify a method to request certificate revocation.

CMP has a Revocation Request; see Section 5.3.9 of RFC 4210.

CMC has a Revocation Request; see Section 6.11 of RFC 5272.

EST does not specify a method to request certificate revocation, but it does specify a way to carry a "Full PKI Request", which could be a CMC Revocation Request.

SCEP does not specify a method to request certificate revocation.

Russ

On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
Do we have a PKIX revocation request format?

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 Mar 2018 12:04:28 -0500

> On Mar 2, 2018, at 4:19 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> On Fri, Mar 2, 2018 at 3:17 PM, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
> If it is a signing key, just sign a CRL for the certificate. Now that is not quite the same as revoking the key but certs are the only things PKIX makes status assertions about.
> 
> Do we have to support self-revocation of certs with only encryption only keys? Probably not.
> 
> Since a very common reason for having to revoke a cert is that the private key is lost entirely any revocation format cannot be the only way to request revocation. So I don't see the relevance of the robot attack.
> 
> 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.

When we had a similar discussion many years ago, the feeling was somewhat different.  If someone has assess to the private key and uses it to authenticate a revocation request, the CA should honor it.  Since the party clearly has access to the private key, thee are many things that party could do that are more harmful than revoking the associated certificate.

Russ

---

From: Ryan Sleevi <[email-masked]>
Date: Mon, 05 Mar 2018 18:26:54 +0000

On Mon, Mar 5, 2018 at 12:04 PM Russ Housley <[email-masked]> wrote:

> On Fri, Mar 2, 2018 at 3:17 PM, Phillip Hallam-Baker <
>> private key is lost entirely any revocation format cannot be the only way
>> to request revocation. So I don't see the relevance of the robot attack.
>>
>
> When we had a similar discussion many years ago, the feeling was somewhat
> different.  If someone has assess to the private key and uses it to
> authenticate a revocation request, the CA should honor it.  Since the party
> clearly has access to the private key, thee are many things that party
> could do that are more harmful than revoking the associated certificate.
>

I think we’re in violent agreement on how it should work - any
demonstration should be accepted as proof. :)

I was highlighting, however, that a policy on which CAs normalize how that
demonstration is done has the unfortunate side-effect of encouraging that
to be the de facto way it is done, which changes the burden from CAs (to
process/verify requests) to reporters/subscribers (to produce requests the
CA will accept). I’m suggesting that’s an exchange of effort that does more
harm than good, ties into the policy aspects of the PKI (what methods are
acceptable to request revocation), and does provide compelling benefit for
those reporting compromise. For those self-requesting revocation, that’s an
aspect of Certificate lifecycle management, and there’s no inherent need
for a signed proof (as demonsrrated by ACME’s protocol and the existing PKI
management tools).

---

From: Russ Housley <[email-masked]>
Date: Mon, 5 Mar 2018 14:18:59 -0500

> On Mar 5, 2018, at 1:26 PM, Ryan Sleevi <[email-masked]> wrote:
> 
> On Mon, Mar 5, 2018 at 12:04 PM Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 2, 2018, at 4:19 PM, Ryan Sleevi <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> I think we’re in violent agreement on how it should work - any demonstration should be accepted as proof. :)
> 
> I was highlighting, however, that a policy on which CAs normalize how that demonstration is done has the unfortunate side-effect of encouraging that to be the de facto way it is done, which changes the burden from CAs (to process/verify requests) to reporters/subscribers (to produce requests the CA will accept). I’m suggesting that’s an exchange of effort that does more harm than good, ties into the policy aspects of the PKI (what methods are acceptable to request revocation), and does provide compelling benefit for those reporting compromise. For those self-requesting revocation, that’s an aspect of Certificate lifecycle management, and there’s no inherent need for a signed proof (as demonsrrated by ACME’s protocol and the existing PKI management tools).

Aren't we already there, based on the CMP, CMC, and ACME protocol mechanisms?  Of course, any report of compromise that is not authenticated by the private key still must be investigated by the CA.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 5 Mar 2018 22:29:40 +0000

On 05/03/18 19:18, Russ Housley wrote:
> Aren't we already there, based on the CMP, CMC, and ACME protocol
> mechanisms?  Of course, any report of compromise that is not
> authenticated by the private key still must be investigated by the
> CA.
If something is to be done in this space (and I'm still not
convinced myself fwiw), then it'd be good to base that on
some public numbers wrt who's been revoking what for which
reasons. I'm not aware of studies on that, but haven't gone
looking.

Cheers,
S.

---

From: "Dr. Pala" <[email-masked]>
Date: Wed, 21 Mar 2018 13:22:50 +0000

+1 to Russ's response.

Some solutions I saw deployed involve the "owner" of the account for
those keys to sign a single CMS with the administrative (or account)
key/certificate and then to submit the generated signed message through
a web-portal.

Mass-revocation (or mass-any-pki-op) is not currently handled well with
existing protocols, if I am not mistaken, unfortunately. So, there might
be mixed proprietary/standard combination that are, today, more efficient.

Things might happen (most probably outside IETF) to address these cases,
especially for IoT environments.

Cheers,
Max

On 3/5/18 4:58 PM, Russ Housley wrote:
> EST does not specify a method to request certificate revocation, but
> it does specify a way to carry a "Full PKI Request", which could be a
> CMC Revocation Request.
>
> On Fri, Mar 2, 2018 at 9:24 AM, Phillip Hallam-Baker
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     I am asking because of a detail in the Trustico situation in which
>     a file of 23K private keys was emailed to a CA to request revocation.
>
>     At the point, the circumstances of that situation are not clear.
>     But I can see a scenario in which it is entirely plausible that a
>     CA reseller would have access to large numbers of TLS private keys
>     and that is when they are either hosting or managing the Web sites.
>
>     The management interfaces that allow Web sites to be wheeled
>     around a data center have become very sophisticated of late with
>     virtualization and much of that infrastructure is 'secret sauce'.
>
>     What might appear to be a five racks of 100 separate machines is
>     likely visible in the management console as one single entity.
>
>
>