Re: Multi-layered PKI implementation
- From: Paul E Condon <pecondon@xxxxxxxxxxxxxxxx>
- Date: Thu, 4 May 2006 13:56:01 -0600
On Thu, May 04, 2006 at 08:15:05PM +0100, James Westby wrote:
On (04/05/06 10:37), Paul E Condon wrote:
On Thu, May 04, 2006 at 05:28:18AM +0100, James Westby wrote:
On (03/05/06 20:29), Grant Thomas wrote:
When large buildings are keyed for locks, locks can be keyed for
different layers of security.
So, there might be the highest key, or skeleton key's used in old
houses that opened all the doors, and multiple levels of sub keys,
down to a key that opens only one lock.
I think I have a grasp on the basics of PKI as it relates to X.509
certificates, but I'm wondering if there is a PKI implementation that
allows for multiple layers of access built into the keys themselves.
PKI is for authentication, not for access control.
I think there is some misunderstanding here, so I'm going say what I
understand by (X.509) PKI. I'll start with X.509 in it's most common
usage (I think), SSL. SSL uses public keys to exchange bulk transport
keys to encrypt the session, but it also provides authentication using
Below Alice is a customer, Bob is an online retailer and Eve is a nasty
Alice -> Bob: I want to by a shiny wotsit from you for 500 monkeys. Can
we encrypt the transaction so I can send you my credit card details?
Bob -> Alice: Sure, my public key is 12345.
Alice -> Bob, thanks, here's our shared secret encrypted with your
Bob and Alice complete their transaction in secret, and Alice get's her
shiny wotsit. Everybody is happy.
Now try again, but this time Eve has tricked Alice in to going to her
website instead (using phishing, DNS poisining etc.) and she has done a
very good job of making it look the same.
Alice -> Eve: This time I fancy one of those big woompas. Can we encrypt
our session again?
Eve -> Alice: (doing her best Bob impression) Sure, my public key is
Alice -> Eve, thanks ...
And Alice is none the wiser.
Now let's try it again with X.509 PKI. Bob now has a valid certificate
from Tony, and Alice has already obtained Tony's public key *over a
secure channel*. (From now on I will omit the request from Alice along
with the useless tat she insists on buying)
Bob -> Alice: Sure, my public key is 12345, and here is my certificate
Alice whips out her calcuator and verifies the signature on the
certificate using Tony's public key. She then checks the certificate
contains Bob's name, Public key, that it hasn't expired etc.
Alice -> Bob: Thanks...
So that's how it works most of the time. Now Eve tries again
Eve -> Alice: Sure, my public key is 6789, and here is my certificate
signed by Tony.
Now, assuming Tony has been doing his job properly one of two things
1) Eve has a valid certificate, but it won't have Bob's name on it.
2) Eve has a fake certificate and Tony's signature will not verify.
Either way Alice knows that Eve is trying to trick her.
Now to get some idea of how access control might come in to it change it
a bit to use the little used other feature of SSL (on the general
Internet at least), client certificates.
A company sets up an agreement with their supplier when they move to
Internet based ordering that the supplier will check that when a member
of staff places an order they will check a list that they have provided
to see if they are authorised to spend that much money. This is a kind
of access control.
To implement this the company sets up their own CA, and provides the
public key to the supplier. They then issue each memeber of staff with a
public key, and associated certificate.
When an employee makes a transaction they enter their name
(Identification), and the supplier then looks up the amount they are
allowed to spend in the list provided by the company, and checks that
this transaction qualifies.
Instead of a password when placing the order the employee will use their
public key (probably in some kind of challenge-response protocol to
check they have the corresponding private key. Without the certificates
an employee can just generate a key pair themselevs and use this, but
with the inclusion of the PKI they cannot.
So, I hope this explains why I think that X.509 PKI as explained above
deals with the authentication of entities, rather that the access
However thinking about it more, SPKI does can give the hierarchical
structure the OP was suggesting. It can actually produce more complex
structures, and also do pretty much the same thing as X.509.
I hope I have explained above why I consider it to be true.
This statement may be true, but only in a very narrow sense that
PKI stands for Public Key Infrastructure.Yes.
It has to do with *public* keys, which are used for encryptingYes.
Encryption is commonly believed to be a way to controlYes.
access to information.
One may have access to an encrypted documentYes.
but, without the key for decrypting it, one does not have access to
However PKI is not normally taken to mean public keys and how they are
used, but instead the infrastrucure that supports them (at least in my
estimation). This is key distribution, authenticity, CAs, RAs, escrow,
OTOH, I think that OP's question does reveal a
misunderstanding of dual key cryptography. Suppose a business wants to
have an information 'czar' who has access to all business documents
generated by employees of the business in the conduct of their work.
For this, dual key encryption has little to offer over more
traditional single key encryption in which the same key is used to
both encrypt and decrypt. For the 'czar' to fulfil his duties, he
needs to have under his control a private database of company
keys. Unlike real physical keys to doors, he does not have to carry
these keys around in a pants pocket. He can't use them unless he is
sitting at a computer that has access to company documents in digital
form. For him, there is no particular benefit in having just one key
for his personal use, and, in any case, it is easy for him to encrypt
his database and keep in his posession only the decryption key of his
Yes, but this appears to be a two level hierarchy, not the most
So it seems to me that a layered structure for public keys has no
target audience of potential users, and therefore may very well not
have been invented.
Does SPKI meet your definition? I'm not sure.
It is certainly very elegant in my opinion. Both in the design and the
idea. It can be used to do some very interesting things that are not
possible with X.509.
But there are lots of useless inventions in this world, so there may
be proposals for layered dual key systems.
The whole business of certificates and certificate authorities has to
do with publishing reliable information about who has *access* to the
private key that matches a published public key. Here layering seems
to be already implemented,
Why do you say this? (I'm genuinely interested)
Are you refering to the hierarchy of CAs that exists?
You could do something where if a cert was issued by a CA higher in the
chain it had more access. However I wouldn't consider this very
practical. And cross certificates might make it difficult by causing the
strucure to have loops and other trickeries.
but has little similarity to the layer
structure of physical keys to doors in a building.
PKI is a tricky
business with lots of nasty little problems for which solutions must
be invented and implemented.
Nasty nasty nasty.
An analogy to the keying of a building
only hides its real difficulties.
Yeah, I would say so.
And we haven't even touched on the other major PKI system, used
frequently on this list. Could that be said to have some form of
hierarchical structure? Probably not one that could be put to much use.
Apologies for the long email, but I felt the need for clarity, and for
me clarity equals verbosity, but it probably doesn't from your end.
I had thought that my reply was already rather verbose. I have no
quarrel with being verbose, and I think OP has gotten the idea that an
accurate answer to his quick question will not be terse. IMHO, any
answer shorter than your present one is surely inadequate, as was mine.
Paul E Condon
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
- Prev by Date: Re: Stuck after upgrade (Unstable)
- Next by Date: Re: More X Problems Today
- Previous by thread: Re: Multi-layered PKI implementation
- Next by thread: Re: Multi-layered PKI implementation