Re: [lamps] Revocation Request Format?

[Phillip Hallam-Baker <[e-mail]>]

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 <[e-mail]> wrote:

> 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]> wrote:
>
>> On Fri, Mar 2, 2018 at 8:08 AM, Ryan Sleevi <[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
>>
>> 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 [e-mail]://www.ietf.org/mailman/listinfo/spasm
>
>
>