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:d.w.chadwick@xxxxxxxxxxxxx]
Sent: Thursday, March 07, 2002 5:19 PM
To: stephen.farrell@xxxxxxxxxxxx
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: 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
*****************************************************************