Subject: X.509 ACs vs. SPKI?

From: Ari Huttunen <[email-masked]>
Date: Wed, 12 May 1999 12:56:34 +0300

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

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

Cheers,

   Ari Huttunen

---

From: Carl Ellison <[email-masked]>
Date: Wed, 12 May 1999 09:22:43 -0700

-----BEGIN PGP SIGNED MESSAGE-----

Hi Ari.

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

>   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

+------------------------------------------------------------------+
|Carl M. Ellison         [email-masked]     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.-+

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 May 1999 16:57:30 -0400

At 09:22 AM 5/12/99 -0700, Carl Ellison wrote:
>[snip]

X.509 ACs offer three methods of binding the attributes to an owner.  They
each offer different advantages and disadvantages.

	(1) Issuer Distinguished Name and Serial Number.  This binds the
attributes to a particular X.509 public key certificate.

	(2) Subject Distinguished Name.  This binds the attributes to a collestion
of certificates that were issued to the same subject, perhaps by different CAs.

	(3) Hash of the Public Key.  This binds the attributes to any certificate
that contains the correct public key.

It is clear how (1) and (2) can be used.  And, (3) seems to provide what
Carl is looking for.  Right?  If so, maybe you can help flesh out that part
of the Internet-Draft.

>others are to be used for chain validation only.

There should be common syntax and semantics for base certificate fields.
Certainly any private extension could be an issue.

I think that the semantics should be the same for any certificate issued
under the same Certificate Policy (CP), regardless of the Certification
Practice Statement (CPS) used by a particular CA.

>	(name <key> N_1 N_2 ... N_k)

The  X.509 public key certificate provides (name <key>).

The X.509 ACs could provide (name N_1), (name N_2 N_3), ... (name N_k).
Where a collection of ACs each contain one or more attributes.

Russ