Subject: Re: X.509 ACs vs. SPKI?

From: [email-masked]
Date: Mon, 24 May 1999 23:55:10 -0700

i beleive that russ's comments are overly restricting the third of the
three binding methods. the hash does not have to be of a public key. it
could be the object digest of any object, e.g. as an applet.  for example,
object x which hashes to y has been assigned z priviliges.

this is stated in 13.7 of the FPDAM after the asn.1

   hoyt

Russ Housley <[email-masked]> on 05/24/99 01:57:30 PM

To:   Carl Ellison <[email-masked]>
cc:   Ari Huttunen <[email-masked]>, [email-masked],
      [email-masked], Carl Ellison <[email-masked]>, Carl Ellison
      <[email-masked]> (bcc: Hoyt Kesterson/US/BULL)
Subject:  Re: X.509 ACs vs. SPKI?

At 09:22 AM 5/12/99 -0700, Carl Ellison wrote:
>[snip]
>
>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.

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.

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

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.

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

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

---

From: Russ Housley <[email-masked]>
Date: Tue, 25 May 1999 14:00:08 -0400

Hoyt:

Thanks for the clarification.

Russ