Re: [lamps] Revocation Request Format?

[Jacob Hoffman-Andrews <[e-mail]>]

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.
>
>
> 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.
>
>
>
> On Fri, Mar 2, 2018 at 3:03 PM, Peter Bowen <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     On Fri, Mar 2, 2018 at 8:08 AM, Ryan Sleevi <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     > 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)
>
>     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
>     <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
>
>
>
>
> _______________________________________________
> Spasm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spasm