[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: X.509 ACs vs. SPKI?
-----BEGIN PGP SIGNED MESSAGE-----
Hi Ari.
At 12:56 PM 5/12/99 +0300, Ari Huttunen wrote:
>Hi,
>
>Has someone made a comparison of what can / cannot be done
>in X.509 Attribute Certificates (draft-ietf-pkix-ac509prof-00.txt)
>that can be done with SPKI certificates? Would there be some ideas
>in SPKI that could be used to enhance X.509 ACs?
>
>My aim here is very pragmatic. I don't observe SPKI as going
>forward, so I would like X.509 ACs to be able to do as much as
>possible...
I perceive SPKI going forward. I'm currently doing an implementation at
Intel, for example, and there are others doing implementations elsewhere.
The first 2 of 4 drafts have been given to the group co-chairs for approval
for giving to the group to go for RFC. I have been slow getting those out,
which may be why you don't perceive action.
OTOH, your question deserves an answer. I remember David Kemp suggesting
that the X.509 community would borrow from SPKI but would probably never
give up its love affair with ASN.1, so the SPKI ideas would be incorporated
into X.509 somehow but not exactly.
>For the sake of conversation, here's a proposal how SPKI certificates
>could be put inside X.509 ACs. I certainly do not claim that this
>works as-is, but it might be made to work.
>
>1) The server checking X.509 ACs is also acting as the CA that
> issues those ACs.
>
>2) The SPKI certificate security fields are mapped as follows:
> Issuer = refers to the X.509 certificate of the server.
> Subject = refers to the X.509 certificate of the client.
> Delegation = ..as in SPKI..
> Authority = ..as in SPKI..
> Validity = attrCertValidityPeriod
I see three problems doing the equivalent of SPKI within X.509 and in
particular with ACs.
1. The identification of issuer and subject is convoluted at best. Missing
is the option that is needed for maximum security (not to mention
anonymity): a public key or the hash of the key. The IssuerSerial option is
subject to constraints not expressed in the certificate. GeneralNames isn't
constrained or defined, AFAIK, in this spec, so that too depends on
constraints not evident in the certificate. The ObjectDigestInfo might be
used to refer to some public key, but that use isn't spelled out -- and even
then, it is only the subject ID that has this option so identification of
the Issuer is left troubled.
2. X.509 does not define the semantics of a certificate, only the syntax. I
find this especially when mapping out the CDSA extensions that extract SPKI
authorization information from existing X.509 certificates (so that our
implementation will accept and use a mixture of certificate types: X.509,
PGP, SPKI, ....). Interpreting an X.509v3 certificate requires a different
trust policy module (in CDSA terms -- the code module that understands the
semantics of each field) for each different CPS -- or, to an approximation,
for each different root key. For example, SET cardholder certificates
define an authorization (permission to use a given PAN/EXP) but plant that
authorization in the CommonName field of the SubjectName. Meanwhile, some
extensions of the SET certificate carry authorization information while
others are to be used for chain validation only.
3. X.509 may be able to define SDSI names, but there is no mechanism for
referring to a fully qualified SDSI name. That means that the only
mechanisms for making an SPKI attribute certificate (one that gives an
authorization to a named entity or group) have to rely on assumptions about
naming conventions. In particular, I see no way to express:
(name <key> N_1 N_2 ... N_k)
in X.509.
--------------------
I've speculated before that one could make an X.509v4 correcting these
problems, but I'm doubtful. X.509 has a lot of baggage that would be
traumatic to discard. It also has a belief system that could be even more
troublesome: that a certificate is a signed document that's entirely up to
the interpreting code to understand. This allows single-application CA and
verification applications, but does not lend itself to multiple-application
code.
- Carl
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1b15
iQCVAwUBNzmq0hN3Wx8QwqUtAQGZjgP/TKTp1flc875QIwYWOa7xrqKWt6nKtZ+H
yTZ8loH6Ln0kzurLgwKLK3HauJMnqv29y+IooAI9d3w3HFQL+Ijodg1vXyOBFv5N
fJHDQ8iyn9kCyNKwCJiMdmuwPgyqqAo6X2PlQWEVirZsWqRKru/NT5UL1esKTvC7
g5rSkimwP/E=
=wSAV
-----END PGP SIGNATURE-----
+------------------------------------------------------------------+
|Carl M. Ellison cme@acm.org http://www.pobox.com/~cme |
| PGP: 08FF BA05 599B 49D2 23C6 6FFD 36BA D342 |
+--Officer, officer, arrest that man. He's whistling a dirty song.-+
References: