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

Re: X.509 ACs vs. SPKI?


Hi Ari.

At 12:56 PM 5/12/99 +0300, Ari Huttunen wrote:
>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

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 

 - Carl

Version: PGP 6.5.1b15


|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.-+