[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on I-D requirement document
Peter,
At 02:32 PM 4/2/97 -0800, Peter Williams wrote:
>The analysis is based on the assumption that
>an SPKI system contains no third party certificate
>issuers, or positive/negative status issuers.
There may be both. The delegation mechanism provides for third party
issuers. One subordinate to the verifier can be thought of as being created
by the delegation (as one creates subordinate CAs in a PEM-like scheme)
while a verifier recognizes an independent issuer's certificates by
referring to SDSI groups, e.g. (ref Newsweek subscribers), or by specific
delegation.
There is also plenty of room for a third party (like an ISP) providing
an always-online certificate or online-test server.
>I'm going to leave X.509 to its fate; as a standard
>its already done its political job, for my purposes.
Offline, I'd be curious about what you consider X.509's political job.
>In other environments, the listing of certificates will
>be crucial using any suitable listing model which the
>users can navigate and search over. real
>people will need friendly cues.
I remember, when I first heard about X.500, looking forward to the day when
I could find the e-mail address of every old friend (or their phone numbers,
for that matter). Then I not only saw it not happen, I saw companies
declare phone lists confidential. Meanwhile, we've seen spammers blossom.
With SPKI/SDSI certificates, the problem is even worse because they can tell
valuable things about the keyholder. So, I have my doubts about the
viability of any large directory service. I'm not about to claim the idea
is dead -- but I wouldn't invest in one.
> "On the other hand, the announced purpose of
> a PKI is to give someone the information needed to permit the
> extending of trust without resorting to on-line exchanges. "
>
>Who announced this definition of a PKI? Perhaps reference it.
This was implicit in the original Diffie-Hellman paper. The advertized
advantage of public key cryptography was that in order to find the right key
to use to send your desired correspondent a private message, you didn't need
a secure channel any more, just a modified phone book -- ie., a PKI.
If you have to engage in any conversation with your correspondent in order
to discover which ID is his in that phone book, that conversation must
be over a secure channel and could have been used to communicate
a conventional secret key (or a public key or its hash).
> "The
> telephone book model does not satisfy that announced purpose. The
> more global the directory, the more ambiguous its names become and
> therefore the less well it performs."
>
>names in listing service, versus names for identifier
>are different notions. The ambiguity properties
>you cite are different for each. You may wish
>to clarify your statement, or embrace both notions. If SPKI
>certs are to be listed in any environment for human-use, they
>will need a human-friendly listing and searching model.
As I mentioned above, I doubt that a directory of certificates will fly.
It has too much going against it.
Making a directory of ID certificates searchable in a friendly manner
isn't hard. The current PGP keyserver at MIT has a very decent human
interface, now that it's been sped up. Of course, giving it
information worth searching on is an open issue.
The performance I was referring to was security performance. The more
names there are in such a directory, the less confident you are that
you have found the key of the person you want to communicate with.
Of course, that's just a thought experiment. If you can't be confident
when the directory contains everyone on Earth, you can't be confident
when it contains only one name.
The name for identifier purposes, if I understand the difference as
you intended it, is superbly achieved with the public key itself.
In that case, there is no ambiguity.
>Does SPKI do POP (to ask the recent PKIX question)?
What's POP? Post Office Protocol?
>I note that "The main purpose of an SPKI certificate is to authorize some
>action,
> give permission, grant a capability, etc."
>
>earlier text had suggested (through
>some convoluted logic) that a major use of the SPKI
>cert is to "engage in trust management" though says that
>"for.. many areas of trust management a person's name is irrelevant."
>
>which areas is the name relevant?
The name is clearly relevant when you want to select an encryption key for
e-mail. In that case, I expect to have a secure address book in my mailer
and to have public keys, e-mail addresses and possibly other information
(like full name, address, phone #, picture, ...) bound to a nickname of my
choosing (or "alias" in the mail lexicon). This is where SDSI names
really shine. A global name for e-mail is of questionable value.
I do have some experience using Lotus Notes at CyberCash and I found its
automatic phone book of employees, with name completion while composing
e-mail, a nice feature. I have since switched to Eudora which also does
name completion -- although in both cases, I miss the TENEX, emacs & tcsh
feature of showing a list of possible completions when the partial name
isn't unique.
I started that paragraph thinking that the Notes example was a
counter-example to my claim that global names are of little value. After
all, Notes uses traditional ID certs in a database as global as it can get
away with. In our case, it was company wide. But it's clear, from
consideration of name completion, that if Notes had used a truly global
X.500 database with keys attached for e-mail, the name completion feature
would have been devalued. If Notes had had the feature of listing
completions, a global database would have made people never use the feature.
So, it's not just security concerns that make a global database worse than
a local one. It's also user-interface issues.
Take for example EPPI (Eudora's plug-in for PGP). When you go to encrypt a
message, you're presented with a "user-friendly" window listing the keys in
your keyring. You get to select your crypto-recipients from that list. I,
however, have a habit of letting my keyring grow as I encounter new
signatures. The larger it grows, the more annoying this directory feature
becomes.
>Is the term "person" referring to human entities, or a generic
> principal notion, here?
Person refers to keyholder and therefore not just human entities. I should
probably do a global replace.
>" The SPKI certificate should be designed to encourage key holders never
> to share their private keys. "
>
>I hate mandatory private key escrow with covert
>access as much as the next person, but
>is SPKI saying that *any* escrow support would constitute a
>security violation of the protocols which use SPKI
>certs?
Yes, a security violation, but not of SPKI protocols.
This isn't a characteristic of SPKI itself. I believe that is a
security truth. To make public key crypto really secure, we need
tamper-proof devices which do their own public key crypto, generate their
own keys and have true hardware random number sources for all kinds of key
generation. There is no room in such an architecture for sharing a private
key with anyone at all, no matter how much muscle that party has, or for
sharing a session key with anyone not on a crypto-recipient list. Of
course, some government (or company) might coerce a citizen (or employee)
into including it on crypto-recipient lists. That's a political battle
which needs to be waged in the open. I personally prefer an American
solution to this: that the FBI and NSA publish public keys in various
popular formats (PGP, S/MIME, ...) and let users decide on a per-message
basis whether to include such agencies as crypto-recipients.
>What is the SPKI design principle which is affected by, or influences,
>the sharing of private keys?
>
>(i.e. is the statement technical, or a political act?)
The statement is technical.
A political statement would be one telling users never to include NSA or FBI
as a crypto-recipient once those TLAs publish public keys.
>"Although we humans are fond of our common names"
>
>The requirements mandate support for nicknames, seemingly
>contained in the cert. Why is a nickname not a suitable common
>name, used in adjunct with the public key value to name a unique
>identifier which the standard seems to be requiring
>exist as a notion distinct from the public key?
Nicknames can be common names. Some of mine are. However,
the nickname is chosen by the person referring to the name.
Here I was trying to refer to a name owned by the named person
and therefore part of a global namespace.
>Is it intended that the cert issuer legally attest
>to the uniqueness of the public key value, and or
>the unique id?
I see no unique ID in an SPKI cert except for a public key
or its hash.
I see no way for a cert issuer to verify key uniqueness, since
many keys are generated without the issuer's knowledge.
Key uniqueness is "guaranteed" by having long keys and very
good, true random number sources driving key generation.
>"The same information can be delivered in a positive statement: a
> periodic revalidation of a certificate or a key. "
>
>what is the difference between validity of a cert and a key?
That's an interesting question. So far, we have addressed only
cert validity. In the X.509 world these are blurred but
I don't expect them to be in SPKI.
Key validity refers to its state of compromise or security.
Cert validity refers to whether a permission has been
granted, revoked or expired.
>how does the positive scheme, in the absence of third parties
>which SPKI outlaws, handle urgent compromise notification
>for keying material?
SPKI does not outlaw third parties -- merely doesn't require them.
As for the notion of urgent compromise notification, imagine some general in
the DoD saying "Well, damn it, we think that code book has been compromised
-- so destroy all copies worldwide, immediately, and issue new ones."
He/she would expect the subordinate to say, "Yes, sir" not "but, sir, there
are units which are out of touch".
One engineering solution might be to prefix each message with any revocation
message, but even then the recall goes out like pond ripples, not
*immediately*. If there are communications lines under the active control
of some enemy, then the recall message might never get to some unit. If you
really want immediate recall, then you need each user of a codebook to check
with home base before each use and get the latest code book ID. Even then,
imagining older hand methods, the encoding process might take an hour after
the code book ID is fetched -- so even then, "immediately" means "within an
hour". So, to permit immediate reaction to the general, you should check
for current code book ID both before starting to encode and immediately
before sending each and every encoded message.
If you want to enable urgent compromise notification, then you need to use
either short expiry certificates (so that one needs a new one from the
issuer before proceeding) or short-duration online tests revalidating (or
not revoking) some cert. You can make the online test give back either a
positive or a negative statement with the same result in terms of both
urgency and security. The reason to choose between positive and negative
will have to do with expected message size and therefore performance.
>Does one separate compromise of system integrity due
>to private key compromise from withdrawal of the authorization
>or other form of privilege grant to oneself?
Yes, I believe so -- but it's not clear that we can.
The cert structure allows for it. We need to work on
key validity -- or at least think it through enough to
decide it's not worth worrying about. The big issue,
to me, is the need to refer to dates securely.
>What status does a failure to periodically revalidate place upon
>signatures of previously validated and accepted
>signed email (if any) when supported by a SDSI cert?
Again, this is a function of dates. The assumption is that
a certificate may be valid for some set of datimes (possibly
with gaps, as noted by Sars). If a signature was made at
a valid time, then the signature should probably be considered
valid forever.
More specifically, if we do invent a mechanism for announcing key
compromise, it should probably include dates after (or between) which the
key was assumed compromised and therefore dates for which statements by that
key are not to be trusted. My guess is that we will want that mechanism
and it is for such a mechanism that I included (subject-info ...) as
an optional cert field.
- Carl
+------------------------------------------------------------------+
|Carl M. Ellison cme@cybercash.com http://www.clark.net/pub/cme |
|CyberCash, Inc. http://www.cybercash.com/ |
|207 Grindall Street PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Baltimore MD 21230-4103 T:(410) 727-4288 F:(410)727-4293 |
+------------------------------------------------------------------+
Follow-Ups:
References: