Subject: RE: Attribute Certificate Policy??

From: Sharon Boeyen <[email-masked]>
Date: Tue, 12 Mar 2002 11:02:05 -0500

I offer my views on the current 509 text in this area (for those who may not
know, I 
am the editor of X.509). Specifically 509 does state that the
certificatePolicies
extension can ONLY be used in public-key certificates and not in attribute
certs.
This was a deliberate and explicit agreement made during discussion on the
PMI 
model for X.509 that as defined in the 4th edition (2000) of X.509.

Unlike PKI, the "authority" to issue the attribute certificate in the first
place, 
was viewed as the primary factor in determining whether or not to accept an
asserted 
privilege. As such the ability to identify and validate this authority was
the 
direction the PMI work took, rather than to assess the policies of an issuer
to 
determine if an AC came from an 'acceptable issuer'. SOA identification and
the 
delegation path process, and associated AC extensions) are the mechanism for
doing that.

However, there was also a requirement to, in the PMI, constrain the
public-key 
certificate(s) that could be used to authenticate an AC holder. 509 provides
two 
ways to do this. First, a specific public-key cert can be required, by using
the 
issuerSerial mode for identifying the holder. Second, the
acceptableCertPolicies 
extension can be used to require that all subsequent privilege asserters
must be 
authenticated with a public-key certificate under a specified certificate
policy.

Unlike PKI where a lot of emphasis was placed on ensuring that the 
issuer was issuing under policies of interest (as there really isn't an
equivalent
in PKI to determining the 'authoritative' issuer), the emphasis for PMI was
on ensuring 
that the issuer was 'authorized' to assign the privilege to the holder and
on enabling
privilege policy specifications to define the rules for target use of ACs. 

I hope that helps explain the 509 standard in this area. I copied the
directory group
on this as the 509 participants are part of that list and I expect some of
them will 
correct anything I got wrong and have additional views as well :-). 

Note that if PKIX identifies requirements that are not met by 509, as always
we want 
to work together on those, but we would want to ensure they are solid
requirements. 

--------------

From my own personal (non editor) viewpoint:

In terms of the two policy types David identified in his email, the 509 PMI
attempts
to deal with the former (which allows AAs to impose constraints on the use
of 
ACs issued) through specific extensions in ACs (e.g. acceptable privilege
policies, target information, time specification etc) and with the latter
(which 
allows target side constraints to be imposed on the set of ACs that can be
used for 
a given application/transaction) through privilege policy. 509 does include 
hooks for linking privilege policy to the use of att certs and does provide
means 
for storing them in directories but does not standardize a syntax for these 
(two sample syntaxes are partially documented in an informative annex, but 
nothing is standardized). 

I agree with Steve Farrell that it is premature to add anything along the
lines 
of certificatePolicies extension to attribute certificates and I personally
don't see
this as a requirement for the PMI model, at least not as currently defined
in 509.

Cheers,
Sharon 

-----Original Message-----
From: David Chadwick [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 5:19 PM
To: [email-masked]
Cc: Christopher S. Francis; Housley, Russ; Ietf-Pkix
Subject: Re: Attribute Certificate Policy??

Hi All

Having implemented a policy based attribute certificate infrastructure
(see www.permis.org and sec.isi.salford.ac.uk/permis for more details) I
have a few comments to make to this thread.

Firstly, there can be a requirement to limit the use of ACs to specific
authorisation policies. In our implementation, each authorisation
policy, or access decision policy (cf ISO 10181-3) is given a unique
OID. 

Secondly, we currently dont have an AC extension to put policy OIDs in,
since the policy extension is only meant to be used with PK certs and
not AC certs. So you would need to update X.509 if you are talking about
putting policy extensions in ACs

Thirdly, there are two policies that are potentially of interest for
ACs. So maybe two policy extensions are needed. The first is the policy
of the AA that issued the AC (what the AC should be used for), and the
second is the authorisation policy controlling the target that is
accepting ACs as credentials/permissions for the access (which ACs the
target can accept). In PERMIS we are only concerned about the latter,
whereas I think the PKIX thread is more concerned about the former. But
consider this. University degrees, Microsoft Certified Engineer, ISO
9000 certified, Visa cards etc. can all be issued electronically as ACs,
signed by the issuing institution. The holder can present these
privilege ACs to any electronic target in order to try to gain access.
So typically an issuer does not try to limit the targets at which the
ACs are deemed to be valid and useful privileges. (A university does not
say where its degrees can be used.) It is the target administrator that
decides which ACs it will trust and this is built into its target access
decision policy (will Org X accept degrees from Univ Y). Clearly a
target (administrator) may wish to consult the issuing policy, if one
exists, before trusting particular AAs, and so a pointer to this in each
AC could be useful (e.g Visa might place restrictions on which targets
can use its electronic credit cards). Parts of the issuing policy are
already in the AC for example, whether delegation is allowed or not. If
the issuer does try to limit the target policies that are applicable to
an AC, it will need to know about the target policies before issuing the
certificates, which might typically be difficult to achieve.

My suggestion would be to steer clear of the existing policies
extension, which is defined for use with PKCerts, and to define new AC
extensions if ones are needed (they can clearly have the same syntax as
the existing policy extension, but give them new extension OIDs). This
more or less agrees with Stephen's email below

David

Stephen Farrell wrote:
> 
> Chris,
> 
> I'd be against the idea of proposing this as an update to the AC profile
> for the following reasons:
> 
> - The profile is in the rfc editor's queue only awaiting son-of-2359 to
>   be processed and such an update would require a re-set back to WG last
>   call (a matter of months!)
> - I don't believe that the use of policy OIDs in ACs is at all well
>   understood and therefore I'd argue to omit it from the profile (one
>   of the things we tried to do with the AC profile was to only include
>   suff that we were pretty sure could work)
> - There may be entirely different policy considerations to address,
>   depending on the context for the use of ACs (e.g. supporting roles for
>   long-term signatures vs roles for access control).
> 
> So, while I'd welcome work starting on this - for both process and
> technical reasons I believe the way to handle it is to write things up in
> a separate I-D. At some point in the future (say if the AC profile were
> being cycled at proposed standard), the two things could be merged if
> appropriate.
> 
> Regards,
> Stephen.
> 
> "Christopher S. Francis" wrote:
> >
> > Sure.  I can pursue it.  Since I don't spend a lot of time here, I'm not
> > exactly sure what the appropriate process is, but what I have in mind is
to
> > do the following:
> >
> > 1) Get some clarification from ANSI and whoever else has an opinion on
> > whether X.509 offers an extension that is intended to be used to carry
> > certificate policy information in attribute certificates.  Perhaps
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they
had
> > something else in mind.
> > 2) Depending on what I find out, propose an update to the PKIX attribute
> > certificate profile that includes an extension to ACs to hold policy
> > information about the issuing authority.
> >
> > Based on your earlier responses, I understand that a certificatePolicies
> > extension could be included in an AC as long as it is marked
non-critical,
> > but it that's only because *anything* can be included as an extension if
> > it's marked non-critical.  It seems to me there should be something
specific
> > in the profile to address the issue of certificate policy.
> >
> > Chris
> > -----Original Message-----
> > From: [email-masked]
[mailto:[email-masked]]On
> > Behalf Of Housley, Russ
> > Sent: Wednesday, March 06, 2002 11:02 AM
> > To: Christopher S. Francis
> > Cc: Ietf-Pkix
> > Subject: Re: Attribute Certificate Policy??
> >
> > Chris:
> >
> > I am not aware of any work in this area.  You can take the lead.
> >
> > Russ
> >
> > At 05:41 PM 3/5/2002 -0500, Christopher S. Francis wrote:
> >
> > >Is there a defined mechanism to specify something analogous to a
> > >certificate policy in an attribute certificate?
> > >
> > >
> > >
> > >In reviewing the PKIX AC profile, I see that the syntax of the
attributes
> > >field is defined by the AttributeType OID, but rather than syntax per
se,
> > >I m looking for a way to specify the particular set of policies,
> > >practices, and procedures that the attribute authority was operating
under
> > >when it issued the attribute certificate.  Seems like this would be
> > >important to relying parties.
> > >
> > >
> > >
> > >X.509 includes an acceptablePrivilegePolicies extension that seems like
it
> > >might to the job, but it was apparently profiled out by PKIX.
> > >
> > >
> > >
> > >Chris Francis
> > >
> > >
> > >
> > >
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email-masked]
> Ireland                             http://www.baltimore.com

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 161 745 8169
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 12 Mar 2002 18:15:44 +0100

Sharon,

Thank you for daring to jump into the discussion.
Your editor view seems to be consistent with your personal view. :-)

> I offer my views on the current 509 text in this area (for those who may
> not know, I am the editor of X.509). Specifically 509 does state that the
> certificatePolicies extension can ONLY be used in public-key certificates 
> and not in attribute certs.

> PMI model for X.509 that as defined in the 4th edition (2000) of X.509.

AAs can issue attributes certificates by making more or less verifications
on the attributes that are granted by them, in the same way like CAs can
issue public key certificates by making more or less verifications on the
identifiers that are granted by them. If I understand the model correctly,
there is no way by simply looking into an AC which "policy" has been used to
issue the AC.

The implication is that AAs can only be trusted by their name, and thus it
will not possible, for example, to trust all the AAs that are issuing ACs -
laid down under one root key - under a given (attribute) policy. 

I have difficulties to understand why the deliberate choice of not having
the equivalent of a certificate policy has been made and the arguments
presented below are not crystal clear to me.

Would you try to explain again ?

Regards,

Denis

> Unlike PKI, the "authority" to issue the attribute certificate in the
> first place, was viewed as the primary factor in determining whether or 
> not to accept an asserted privilege. As such the ability to identify and 
> validate this authority was the direction the PMI work took, rather than 
> to assess the policies of an issuer to determine if an AC came from an 
> 'acceptable issuer'. SOA identification and the delegation path process, 
> and associated AC extensions) are the mechanism for doing that.
> 
> public-key certificate(s) that could be used to authenticate an AC holder. 
> 509 provides two ways to do this. First, a specific public-key cert can 
> be required, by using the issuerSerial mode for identifying the holder. 
> Second, the acceptableCertPolicies extension can be used to require that 
> all subsequent privilege asserters must be authenticated with a public-key 
> certificate under a specified certificate policy.
> 
> equivalent in PKI to determining the 'authoritative' issuer), the emphasis 
> for PMI was on ensuring that the issuer was 'authorized' to assign the 
> privilege to the holder and on enabling privilege policy specifications 
> to define the rules for target use of ACs.
> 
> directory group on this as the 509 participants are part of that list and 
> I expect some of them will correct anything I got wrong and have additional 
> views as well :-).
> 
> Note that if PKIX identifies requirements that are not met by 509, as
> always we want to work together on those, but we would want to ensure 
> they are solid requirements.
> 
> --------------
> 
> In terms of the two policy types David identified in his email, the 509
> PMI attempts to deal with the former (which allows AAs to impose constraints 
> on the use of ACs issued) through specific extensions in ACs (e.g. acceptable 
> privilege policies, target information, time specification etc) and with the 
> latter (which allows target side constraints to be imposed on the set of ACs 
> that can be used for a given application/transaction) through privilege policy.
> 509 does include hooks for linking privilege policy to the use of att certs and 
> does provide means for storing them in directories but does not standardize 
> a syntax for these (two sample syntaxes are partially documented in an 
> informative annex, but nothing is standardized).
> 
> lines of certificatePolicies extension to attribute certificates and 
> I personally don't see this as a requirement for the PMI model, at least not 
> as currently defined in 509.
> 
> Cheers,
> Sharon
> 
> > > exactly sure what the appropriate process is, but what I have in mind
> is to
> > > do the following:
> > >
> > > >X.509 includes an acceptablePrivilegePolicies extension that seems
> like it

---

From: "Christopher S. Francis" <[email-masked]>
Date: Tue, 12 Mar 2002 13:44:02 -0500

Thank you Sharon.  I was hoping you’d weigh in on this.
 
…snip
Unlike PKI, the "authority" to issue the attribute certificate in the first place, 
was viewed as the primary factor in determining whether or not to accept an asserted 
privilege. As such the ability to identify and validate this authority was the 
direction the PMI work took, rather than to assess the policies of an issuer to 
determine if an AC came from an 'acceptable issuer'. SOA identification and the 
delegation path process, and associated AC extensions) are the mechanism for doing that. 
…end snip
What concerns me about this approach is that it seems plausible that the AAs themselves may want to put something in the certificate that clearly and unambiguously links the certificate to a policy document that identifies things like usage constraints and liability limits associated with the assertion of whatever privilege is being granted.  This is especially true if an AA issues ACs under more than one policy ….. say for example with varying degrees of liability, depending on the applicable practices and procedures.
In any case, if I understand you correctly it seems that the acceptablePrivilegePolicies extension would be an appropriate place for the AA to impose constraints such as those referenced above.  I’m not a lawyer, so I’m not even sure it’s necessary from a legal stand point, but I hope to get some more insight into that aspect shortly.
Chris
From my own personal (non editor) viewpoint: 
In terms of the two policy types David identified in his email, the 509 PMI attempts 
to deal with the former (which allows AAs to impose constraints on the use of 
ACs issued) through specific extensions in ACs (e.g. acceptable privilege 
policies, target information, time specification etc) and with the latter (which 
allows target side constraints to be imposed on the set of ACs that can be used for 
a given application/transaction) through privilege policy. 509 does include 
hooks for linking privilege policy to the use of att certs and does provide means 
for storing them in directories but does not standardize a syntax for these 
(two sample syntaxes are partially documented in an informative annex, but 
nothing is standardized). 
I agree with Steve Farrell that it is premature to add anything along the lines 
of certificatePolicies extension to attribute certificates and I personally don't see 
this as a requirement for the PMI model, at least not as currently defined in 509. 
Cheers, 
Sharon 
 
-----Original Message----- 
From: David Chadwick [ mailto:[email-masked]] 
Sent: Thursday, March 07, 2002 5:19 PM 
To: [email-masked] 
Cc: Christopher S. Francis; Housley, Russ; Ietf-Pkix 
Subject: Re: Attribute Certificate Policy?? 
 
Hi All 
 
Stephen Farrell wrote: 
> > exactly sure what the appropriate process is, but what I have in mind is to 
> > do the following: 
> > 
> > certificatePolicies, perhaps acceptablePrivilegePolicies, perhaps they had 
> > something else in mind. 
> > extension could be included in an AC as long as it is marked non-critical, 
> > it's marked non-critical.  It seems to me there should be something specific 
> > From: [email-masked] [ mailto:[email-masked]]On 
> > Behalf Of Housley, Russ 
> > >In reviewing the PKIX AC profile, I see that the syntax of the attributes 
> > >field is defined by the AttributeType OID, but rather than syntax per se, 
> > >practices, and procedures that the attribute authority was operating under 
> > >X.509 includes an acceptablePrivilegePolicies extension that seems like it