[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPKI signing keys only
>
> First, in this context, I strongly prefer the term "Identification key"
> to "entity/data origin authentication". The former is a noun (a thing),
> the latter verb(s).
I don't have any quarrel with the terminology - I'm as happy with
"entity identification" as with "entity authentication", but there is
a distinction to be made between realtime and offline identification.
> > 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.
> >
> Bob and Karl and I (and many others) all apparently agree that SPKI
> should _never_ provide keys for communication session key establishment.
>
> Indeed, Photuris and (I believe) Oakley are _very_ careful to never sign
> the communication key itself. The communication key is derived
> exclusively from ephemeral material.
(you mean Carl, right? I know a Karl from RADIUS but not from SPKI :-)
(and I don't know what you mean by the last sentence - of course
communication keys are always ephemeral, otherwise you would have
Manual key distribution. No need for a PKI at all.)
To be useful, Photuris and ISAKMP/Oakley must provide some proof that the
communication endpoints are who they claim to be - Identification
or Authentication as you prefer.
That is quite a different function, and has quite different handling
considerations, than providing proof that you signed a contract
(Non-repudiation) or wrote a letter (Data Origin {I|A}). I might use
public keys certified by SPKI certificates to Identify myself in SSL or
IPSEC connections every day and not worry too much about keeping the
corresponding private key on my hard drive. But I might prefer to keep
my contract signing key in a smart card and only plug it in when
signing contracts.
> So, let me say again, SPKI should _never_ provide key establishment, and
> this should be clearly stated.
Fine with me. But if SPKI certs can never be used with Photuris or
ISAKMP/Oakley or TLS, the working group should clearly state that intention
so that communication protocol designers don't have to worry about handling
SPKI certs.
Follow-Ups: