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

Pointer to new I-D


 I'd like to bring to the notice of this group my I-D that I believe is
 very much in synch with most of what this group believes in.


One little catch though, my I-D works on the X.509 standard. I was
 warned by Steven M. Bellovin that this might not be received by
this WG particularly well. However, Im prepared to take this chance,
since my I-D is not exactly bound to the X.509 standard (viz, we could
just as well do what it says using S-Expressions)

I do understand the antipathy SPKI WG has towards ASN.1. But my
I-D is NOT all about trying to make SPKI type stuff work within
the X.509 framework.

I'm not advocating X509 as much as Im trying to advocate:
(1) the "Atomic" concept - by which we break things down to
"unit-attestations"  -- mix-n-match these on the fly, just before
sending to the other party.
(2) the Attribute-Assertions concept, which I believe to
be the superset of all other types of certs.

Further, it was suggested to me that since Im using X.509 standard, I'd
submit it to the PKIX WG.  I find that as far as the basic philosophy of
goes, the SPKI is more sympathetic to my point of view. However, I have
sent a pointer
to this effect to the PKIX WG, but got no takers,  probably because I start
off with the
premise that Certificates are NOT about identifying an entity.

The trouble is with the PKIX as described in RFC 1422 .
 X.509,  IMO by itself does not preclude my way of  thinking. Given this, I
used the X.509
ramework, simply because it's already out there.

Abstract of the I-D

The existing PKI has a few inherent limitations like:

  1. It is implicitly assumed that the two trading parties have ONE
  mutually trusted third party that can attest ALL of each
  party's attributes. It provides no mechanism to separate out the
  fields in a certificate for attestation by different Certification

  2. This standard in no way gives the flexibility to expose only
  certain fields of a certificate to the other party.

This memo proposes a model which, while working well within the
X.509v3 framework, overcomes these limitations by
breaking up a certificate into pre-signed "unit attestations"
referred to as "Atomic Certificates" and packaging them in the
X.509v3 format only at the time of sending the certificate to the
other party.

Narayan Raghu
IBM Bangalore