RE: NEW Data type for certificate selection ?

[r1naray@xxxxxxxxxx]

Hello,

A sort of tangential question.

I'm not sure if you have glanced through the I-D on Atomic Certificates.

I was just wondering if anyone had any suggestions as to negotiation of
required Attributes for such a setup.
imho, this concept permits hiding from the user lots of gory details about
required attributes, since the setup
permits it to be automated.

There are two questions here :
Negotiating the trusted root  - (will affect chaining, as has been pointed
out)
Negotiating the required Attributes - (will be very different with Atomic
Certificates, imho)

We are thinking of a trial run on Atomic Certificates, and for that, we
need to have a pilot protocol that uses it.

Any comments are welcome.

Thanks,
Regards,
narry

PS: for those who have not read the draft at
http://www.ietf.org/internet-drafts/draft-raghu-atomic-certificates-00.txt
here's a very brief writeup of the concept.

Atomic Certificates are basically X.509v3 certificates containing NO
subject Name, and containing exactly ONE
extension, with criticality bit set to true. The peer is expected to
collect Attribute Certificates, for different attributes
signed by different CAs over a period of time. The peer would mix-n-match
and send to the other peer ONLY those
certificates that are required by the other peer, for validation. All the
Atomic Certificates have the same public key.
The whole thing centers around the concept that Certificates are not
documents that identify an entity, but are
documents that attest to an attribute of an entity.