RE: Attribute Cert Policies Rationale

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Title: Message

Chris and Steve:

 

There is another advantage to keeping the policy and attribute separate.  One can envision a common set of attributes understood by a variety of applications.  With the approach of keeping the policy separate, not only do you not have exponential growth in OID, the applications that do not understand or care about the policies can process the attributes certificates by ignoring the policy extension and those that care can process and enforce the policy.

 

The only objection I envision to having policy is adding a field to be processed.  If the extension is non-critical, applications that understand the policy can ignore it and still use the certificate.

 

The advantages seem to be numerous.  Having the flexibility is better.

-----Original Message-----
From: Christopher S. Francis [mailto:chris.francis@xxxxxxxxxxxxxxxx]
Sent: Friday, December 27, 2002 9:47 AM
To: Santosh Chokhani; 'Stephen Kent'
Cc: 'Ietf-Pkix'
Subject: RE: Attribute Cert Policies Rationale

Steve,

 

What Santosh said.  Overloading the attribute value OID with policy information seems like a messy solution to me that will not scale well. 

 

Furthermore, it is conceivable that applications may want to take different actions when they don’t understand the syntax of a particular attribute vs. when they don’t find the policy under which it was issued acceptable.  Using the attribute value OID to convey policy information makes it impossible to make this distinction.

 

Chris

 

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]On Behalf Of Santosh Chokhani
Sent: Monday, December 23, 2002 5:39 PM
To: 'Stephen Kent'; 'Chris @ work'
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.

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx] On Behalf Of Stephen Kent
Sent: Monday, December 23, 2002 3:43 PM
To: Chris @ work
Cc: Ietf-Pkix
Subject: Re: Attribute Cert Policies Rationale

At 3:11 PM -0500 12/23/02, Chris @ work wrote:

Steve,

 

I considered that approach initially, but rejected it becuase it inhibits interoperability.  If issuers have to define a unique OID for an attribute type to reflect their particular policy, then this makes it difficult for AC processing software to be developed to support a common set of attribute types (such as those defined in RFC-3281 for instance).

 

Chris

 

Chris,

 

I would have expected software that makes use of ACs to have the OIDs for acceptable policies (and meaningful attributes) specified as parameters to the software, so I'm not sure why using different OIDs to represent attributes asserted under different policies would be problematic.  can you explain in more detail?

 

Steve