[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]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:stephen.farrell@xxxxxxxxxxxx
> 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: D.W.Chadwick@xxxxxxxxxxxxx
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
*****************************************************************
begin:vcard
n:Chadwick;David
tel;cell:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:d.w.chadwick@xxxxxxxxxxxxx
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500: http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard