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

Re: Attribute Cert Policies Rationale

To: "Chris @ work" <chris.francis@xxxxxxxxxxxxxxxx>
Subject: Re: Attribute Cert Policies Rationale
From: Stephen Kent <kent@xxxxxxx>
Date: Mon, 23 Dec 2002 15:42:36 -0500
Cc: "Ietf-Pkix" <ietf-pkix@xxxxxxx>
In-reply-to: <>
List-archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-id: <ietf-pkix.imc.org>
List-unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
References: <><><>
Sender: owner-ietf-pkix@xxxxxxxxxxxx

Title: 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

Follow-Ups:
- RE: Attribute Cert Policies Rationale
  - From: Santosh Chokhani

References:
- RE: Attribute Cert Policies Rationale
  - From: Roger Younglove
- RE: Attribute Cert Policies Rationale
  - From: Stephen Kent
- Re: Attribute Cert Policies Rationale
  - From: Chris @ work

Prev by Date: SCVP Compliance Matrix
Next by Date: RE: Attribute Cert Policies Rationale
Previous by thread: Re: Attribute Cert Policies Rationale
Next by thread: RE: Attribute Cert Policies Rationale
Index(es):
- Date
- Thread