[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SPKI signing keys only

> From: "William Allen Simpson" <wsimpson@greendragon.com>
> 
> > From: Carl Ellison <cme@cybercash.com>
> > At 04:21 PM 6/15/97 +1000, Bob Smart wrote:
> > >Either way it seems that public key infrastructure should only
> > >cover signing keys. Mixing in other sorts of keys into that infrastructure
> > >is unnecessary and confusing. Or maybe I'm missing something?
> >
> > I concur completely as do the other authors of the SPKI draft, I believe.
>
> Thank you.  Now we need to make this more clear in the SPKI draft.
> 
> I don't really like the term "signing keys", though.  Signing is an
> activity.
> 
> I usually explain it as:
> 
>     Identification key: a long-term key that is associated with a
>     particular role, person, machine, or process (usually a
>     public/private key pair).
> 
>     Communication key: a short-term key used for a message (usually an
>     "ephemeral" symmetric secret key).

I think Bob Smart's comment referred only to public/private key pairs,
not symmetric keys.  Among public keys, there are those intended to
authenticate an individual (realtime "entity authentication") or message
(offline "data origin authentication") and those intended to be used to
establish symmetric session keys ("key transport" or "key agreement").
Bob, I believe, wished to have SPKI explicitly acknowledge the use
of key pairs for "signing" (DOA and EA) but not for session key
establishment.

Others have found a need to make the distinction between signing keys
and key establishment keys.  If SPKI chooses not to make the distinction,
it will just be deferring the decision to private agreement among
implementors.  One way of being "simple" is to avoid standardizing
such usage conventions.  I question the wisdom of that, but since there
is already a PKI architecture that does provide a framework for
standardizing the meaning of various "auths", it is probably good for
SPKI to *not* standardize them, and instead defer the definition of
"auth" meanings to bilateral agreements and community usage profiles.

We'll see which approach is most successful.


> Does this make sense to the rest of you?  Could we expand the
> SPKI terminology section?  Could we clarify the purpose of SPKI?

Clarification is always good :-).
Follow-Ups: