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

Re: X.509 ACs vs. SPKI?



Carl Ellison wrote:

> Ed Gerck wrote:
> >
> > "Ellison, Carl M" wrote:
> >
> > > ... for secure binding,
> > > the hash of the public key is a fine globally unique identifier and an
> > > unanchored text name is wide open to abuse.
> >
> > I disagree. The hash of the public-key is also open to abuse since it
> > does not securely include that key's validity date, does not include an
> > originally secure reference to a valid revocation mechanism linked to
> > the identity certificate from whence that public-key came and cannot
> > contain other warranties or insurance by extension from the identity
> > certificate itself.  Please see  my former e-mail.
> >
> > However, I agree if  one uses the whole identity certificate hash -- not
> > the public-key hash. This was also discussed in my former e-mail.
> >
>
> It is not clear to me that you would want to revoke an identifier.  An
> identifier is just a byte string.  The hash of the public key is a byte
> string that you know is globally unique and is tied 1:1 with a private
> key.

In Logic, one distinguishes between material values and formal values.
The formal value of the public-key hash is its byte string (as you say)
and is immutable after issuance. On the other hand, the material value
is what it denotes and this can change at any time -- for example, it may
now denote a revoked key. Thus, the material value of the same formal
identifier may change at any time.

In software engineering terms, the public-key hash is a pointer and we
likewise distinguish between the pointer's value (which would be its
value as a byte string ) and what it denotes (its validity, use, warranties,
etc.) -- usually called its attributes.

Thus, likewise in Logic, I believe my sentence above is clear -- we need
to be able to look up also the hash's material value, not only its formal
value, if we are willing to designate any material significance to its use.
That is why the hash alone cannot be used and such would be a serious
security fault if you are dealing with material values.

Of course, if you are dealing only with formal values then ...who cares
what that byte string denotes? May not even be a key-hash, may have
been revoked, may belong to Khadaffi or Milosevic. But, then, why use
it in an attribute cert at all? Instead, using anything (and, saying so) will
be safer.

So, in order to help prevent a con game, misuse or abuse after a key
compromise,  expiration, foul-up, etc. I have to be able verify now
what that pointer denotes; which I can only do if I have its context,
its reference -- and this is the certificate where it is referenced, which
I can gain check for its own references and so on until I am satisfied.

At the end, it should be like a domino game -- if the public-key is revoked,
everything that relies on it should fall. Note that the same does not necessarily
apply if the public-key is expired but is not revoked.

And, of course, just looking at that public-key hash will not be very
revealing  ;-) I need its material values even if I myself issued it.

Cheers,

Ed Gerck
Follow-Ups: References: