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

RE: Attribute Cert Policies Rationale



Title: Message
Steve:
 
I think you are probably right about the clients.  I do think that to reduce the explosion of OIDs and not overloading the meaning of privileges makes it more attractive to keep the privilege and policy apart.
 
IMHO, given all the various atomic fields and extensions in both public key and attribute certificates, the better approach is to keep the two apart.  It offers us the best long term flexibility.
 
-----Original Message-----
From: Stephen Kent [mailto:kent@xxxxxxx]
Sent: Monday, December 23, 2002 5:58 PM
To: Santosh Chokhani
Cc: 'Ietf-Pkix'
Subject: RE: Attribute Cert Policies Rationale


Steve:
 
Let us assume that there are n attributes and m policies.
 
Chris's approach will require you to register n + m OIDs and an application will have to know about no more than n + m OIDs.
 
The other approach will require you to register n * m OIDs and an application may have to know about up to n * m OIDs
 
Thus, the second approach makes the OIDS proliferation faster.  How fast, depends on n and m.

Santosh,

One starts with the assumption that there are N attributes to begin with, and Chris is suggesting creating a facility to represent M policies.  So, the new registration burden under Chris's scheme is M policy OIDs, and under my suggestion, it is up to N*M. So the added registration burden is (N-1)*M IF every attribute is issued under every policy, which may or may not be the case.

While in the worst case an app might have to be configured with N*M OIDs, I suspect that in practice any app will deal with a subset of attributes and policies and thus the config burden is likely to be considerably less than the max.

Your actual configuration burden may vary :-)

Steve