Subject: Re: short-lived credential issuance

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Oct 2002 14:27:44 +0100

Hi Trevor,

One of the decisions that we made early on was that the SACRED credential 
server can treat the credential data as an opaque blob (as far as the 
protocol is concerned, your own implementation might do more than that,
of course).

Another decision we made was to introduce a hint in the download 
response as to the duration for which this downloaded credential ought
to be used at the client. (Just a hint, since the server can't enforce
anything).

Putting those two together would I think mean that SACRED is usable
as-is for short-lived/transient credentials.

In order to get the best behaviour you might want to define something
other than pkcs1#15 as the default credential format, and/or write a 
separate I-D that adds a MUST honor the download response TTL for clients, 
but other than that I can't see anything missing. (Though that's no 
guarantee - you need to check for yourself:-)

Cheers,
Stephen.

Trevor Perrin wrote:
> 
> Greeting SACRED,
> 
> A question about a possible use case:
> 
> It seems that SACRED could be used for issuing short-lived credentials
> (certs+keypairs).  To client software, there wouldn't be much difference
> between retrieving a static, long-lived credential or getting a transient,
> freshly-issued one.
> 
> Short-lived credentials are useful because they expire quickly so don't need
> to be revoked, and don't need to be stored on the server (the server might
> be stateless, and simply refer all authentications to a legacy auth server
> like RADIUS).
> 
> SACRED isn't ideal for cert issuance.  A protocol designed for it, like
> IPsec's PIC, can deal in certificate requests and thus allow the client to
> keep secret his private key, and have input into the certificate contents.
> But having a single, general protocol for client apps to retrieve either
> static or transient credentials might cause people to use SACRED for this
> anyways.
> 
> So should the SACRED protocol take this into account?  I'm not sure how,
> maybe no changes are needed.  Maybe there could be a well-known selector
> named "transient", for example.
> 
> I'm just curious if this is worth thinking about further, or if it's out of
> scope.
> 
> Trevor

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 1 Oct 2002 10:44:37 -0400

Hi,

I've definitely been interested in this. In the higher ed world these
short lived certs have frequently been referred to as "junk certs".

SACRED is sufficient to make a bootstrapping protocol for junk certs
but isn't ideal. An ideal protocol would take some sort of CRL (or
simplier format?) from the client and have the server sign it after
the client has authenticated.

This can be implemented as an extension to the base sacred protocol
and is probably not worth cluttering the base document.

Larry

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Tue, 1 Oct 2002 09:57:59 -0700 (PDT)

> short lived certs have frequently been referred to as "junk certs".

One reference to work along this line is:

  http://www.citi.umich.edu/projects/kerb_pki/

> but isn't ideal. An ideal protocol would take some sort of CRL (or

I think you mean CSR.

> and is probably not worth cluttering the base document.

Could be.  One could also imagine a SASL-enabled version of one or more of
the many standard certficate management protocols.  I don't know enough
about any of them to know if one is more suitable for perversion than the
others.

 - RL "Bob"

---

From: Lawrence Greenfield <[email-masked]>
Date: Tue, 1 Oct 2002 13:42:23 -0400

Date: Tue, 1 Oct 2002 09:57:59 -0700 (PDT)
   From: "RL 'Bob' Morgan" <[email-masked]>
[...]

   I think you mean CSR.

Yes, of course. Thanks.

Yep. SACRED is tempting since you can imagine a SACRED server that
either can sign junk certs (for temporary authentication purposes) or
makes a long term S/MIME cert available for e-mail purposes, and does
so in the same protocol.

Larry

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Oct 2002 11:34:43 +0100

> about any of them to know if one is more suitable for perversion than the

The salient fact is the "...many standard protocols..." above - I don't think
we really want to go adding yet another one. Of course, what you do in 
private is your own business, but re-inventing PKI enrollment is certainly 
not part of our charter, and probably isn't the type of activity to which 
you want to admit openly when there are PKI-types about:-)

Stephen.

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Thu, 3 Oct 2002 11:42:17 -0700 (PDT)

On Tue, 1 Oct 2002, Lawrence Greenfield wrote:

> ...

I can imagine a very useful server that both issues certs (as a CA or a
proxy for a CA) and supplies long-term saved credentials, but I don't see
why this requires using the same protocol for both.  As Steven says,
making SACRED compete with CMP/CMC/etc regarding enrollment is likely to
make people upset.  Seems to me the more likely standards approach would
be creating the desired enrollment protocol (the sort of enrollment
protocol that would, for example, provide the functionality that the UMich
KX509/KCA needs), out of one of the existing ones.

A quick glance at specs and drafts regarding CMP and CMC shows that each
is claimed to operate over a variety of "transports" (as stated in
separate I-Ds), and each is capable of being sent via HTTP.  A BEEP
transport for these could presumably work more or less like HTTP but would
provide SASL.  No doubt there are hidden complexities involved in applying
SASL authentication to the cert-management process.

 - RL "Bob"