[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Alternative authentication & SPKI
Nick Szabo, <szabo@best.com>, writes:
> Has any work been done on using SPKI or PolicyMaker
> with alternative authentications schemes, such
> as ZKIP, designated confirmer signatures,
> undeniable signatures, etc.? To what
> extent to SPKI and PolicyMaker depend on
> the features of traditional public key
> signatures -- e.g. nonrepudiation and an unrestricted
> set of verifiers?
Good question. A simple SPKI sequence might consist of a certificate,
which has the issuing key, subject, validity, and authorization tag;
followed by the signature by the issuing key on the certificate, and then
the requested action by the subject key. The verifier checks the signature,
and if the issuing key of the cert is trusted to authorize the requested
action, it is accepted.
SPKI includes the possibility of online signature re-validation in
the validity field of the cert. In fact, if the "reval" or "one-time"
options are specified here, I'm not sure a <signature> is even necessary
in the sequence. It is the online verification which will actually tell
whether the cert is valid. (Maybe the <signature> is necessary, not
so much to confirm the authority being granted, but to authenticate the
URL where the verifier is supposed to check to revalidate the certificate?)
An interactive signature validation protocol might be incorporated here,
with a new type of online signature validity check. A zero knowledge
or undeniable signature interactive protocol would have much the same
semantics as a simple certificate revalidation query, although the
details of the messages would be different.
Earlier versions of the spec considered blind signatures, where the issuer
does not see some aspects of the certificate being signed. Usually you
want to have some restrictions on the blinding, so that the issuer could,
for example, control the auth tag without knowing the subject.
This could be captured with a variant on the signature object. The
chosen blind signature protocol would be defined in the <pub-sig-alg-id>
(associated with the key) or in the <sig-val> (associated with the
signature). Any fields of the certificate which were controlled via
restrictive blinding would have to be encoded in the <sig-val>, and the
signature verification would include the step of checking those fields in
the cert for consistency with the values in the <sig-val>. For example,
if the auth tag was implied by the exponent used in a blind RSA signature,
the signature verification step would have to check that the tag in the
cert matched the exponent in the signature.
This stretches the SPKI model because signature verification now needs
access to more than just the hash of the signed object, it needs access
to (the hash of?) a subpart of the signed object.
Another idea where there has been some work recently is group signatures,
where it can be verified that a signature is by some key in a set, but
you can't tell exactly which key issued it. In some designs the set of
keys is given explicitly, while in others it is defined implicitly as
keys which are signed by a published group-membership key.
The first model could be syntactically expressed very nicely using SPKI's
k-of-n construct as the issuer of a cert, with k = 1, so that the cert
is saying "one of these n keys is making this assertion, but you don't
know which one". k-of-n is only supposed to be used as the subject, but
it is tempting to imagine extending the syntax for this case. You would
then also use the 1-of-n as the principal in the signature, with a custom
verification algorithm as is necessary for the group signature.
The second model can be thought of as a form of blind delegation, in
which the group-membership key has some authority, it delegates it to the
group key which you never see, and the group key then passes it on in a
signature of its own. You don't know the group key, but the verification
algorithm lets you confirm that the final signature is issued by a key
signed by the group-membership key (Camenisch & Stadler, Crypto 97).
In SPKI terms this could be considered a signature issued by the group-
membership key, as long as that key had delegation authority. The fact
that a second, unknown, key played a part is not important in terms
of following a delegation chain (although it helps maintain privacy
for the signers). So this could be handled by a custom verification
algorithm in the signature field, with the additional requirement that
the signer must be authorized to delegate.
Hal Finney
Follow-Ups: