Re: [lamps] Revocation Request Format?

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

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
>