[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: X.509 ACs vs. SPKI?
Tony:
I will reply in second-order ;-), to save time.
Tony Bartoletti wrote:
> I should have used (exceptional!) instead of (exceptional?) but
> I suppose there are other avenues of attack.
> If someone actually stole your secret key, they might have a new
> cert produced with alternate attributes. Thus keys (and key-hashes)
> would be identical, yet the certs (and cert-hashes) differ.
As well as their issuance dates would differ-- which however could not
be seen just by relying on the dateless key-hash information, as the SPKI
verifier must do. So, the SPKI verifier would a priori have less information
than a X.509 verifier -- who would see the whole identity cert hash and could
thus verify when that public-key was certified and whether that certificate is
listed in any CRL since.
But, this is NOT the case I was targetting when I commented that
using just the key-hash was insufficiently secure. The several security
faults I alluded to (please see the relevant posting) would not
depend on the (harder) case of stealing the private-key but on the
(trivial) case of copying the public-key -- even for a SPKI-SPKI
cert/verifier, which is however not the case of this thread.
> The central issue of the posting was in the second paragraph.
> Namely, (even given key-pair uniqueness) how far can one get
> when the verifying party sees only the (authenticated) hash of
> another key, rather than the authenticated hash of a certificate.
>
> My (tentative) answer for SPKI was that key-hash is sufficient,
> given that the verifier is the issuer, and is presumed to have
> the corresponding (unique) certificate in hand already.
I note that my comments were not SPKI-SPKI but SPKI-X.509.
But let me comment that the SPKI-SPKI case you mention can be even
simpler. In fact, who needs even the key hash in that SPKI attribute cert?
Simply by signing the SPKI attribute cert with the corresponding private-key,
the issuer would force himself at a later date (when he becomes the verifier)
to use the corresponding public-key in order to verify the attribute cert's
signature. No need for a key hash entry for that same public-key in the
attribute cert -- the binding of the attribute with that public-key is implict
but strong, in the cert signature itself.
Things do tend to get simpler thus, when one is talking to himself.
However, if communication or e-commerce enter the picture and the
verifier is no longer the issuer, then you can no longer assume that to
each public-key there is a unique certificate (as you write above). This
is not Kansas anymore ;-)
Take the case of "Joe Spki" that needs to verify an X.509 attribute
cert issued by a CA, which was made by binding an attribute with the
hash of his public-key (as defined in SPKI terms). Now, shouldn't
"Joe Spki" become suspicious if the X.509 attribute cert was issued
yesterday but his public-key referred to that hash was certified some
five years ago? Yes, of course. But "Joe Spki" cannot verify this unless
he relies 100% on his memory to cover the gap between that dateless
hash and today -- and recall which CA he used, as well as what serial
number that certificate had, whether that serial number was not in
duplicate for that CA, etc. It is entirely possible that he only finds a cert
issued five years ago (and, suppose, expired), while failing to find *in that
computer* a newer and valid cert for that same key. The reverse is also
true and it can happen that Joe finds a valid cert issued recently for that key
but fails to find the CRL for a cert issued for that key five years ago -- when
the private-key was stolen by an ActiveX control.
There are other examples of this time logic, but the basic fault here is
dissociating the public-key with the certificate that validates it. By floating
the public-key, SPKI floats its context. This is not a problem if you are
talking to yourself, since you yourself supply the trust link to yourself that
builds the context you yourself accept and must bear the risk for -- but,
only then.
At the end, I believe however we are in agreement. Because in your original
e-mail you wrote:
>OK, that doesn't get one very far ... I can't see how to leverage the
>same assurance for longer chains [ie, longer than 1]
I can't see either -- unless the SPKI verification chain has length 1 (the
issuer is the verifier), reliance cannot even be defined. But then,as I
commented above, for an attribute certificate from myself (issuer) to
myself (verifier) not even the key hash is needed in an SPKI attribute
certificate -- I just sign the cert and the signature will implictly bind that
key hash with any attributes. Can this be useful? Perhaps, as a type of
crypto memory for myself -- but not for this X.509 ACs vs. SPKI
thread.
Is there a solution? I believe so as I wrote before, both for SPKI-SPKI
as well as for SPKI-X.509 -- by simply using the whole cert hash instead
of the key hash. Then, the key is referred together with its validation and
revocation context and I don't have to worry myself whether I am
correctly recalling its original context or not.
Comments?
Cheers,
Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck egerck@mcg.org.br
References: