Subject: Re: Attribute Certificate Policy??

From: "Housley, Russ" <[email-masked]>
Date: Wed, 06 Mar 2002 11:01:43 -0500

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

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 7 Mar 2002 08:57:48 -0500

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:

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 07 Mar 2002 09:21:15 -0500

Chris:

I think that certificatePolicies is the correct extension to use.  The 
profile does not need to be updated unless you think that there is a reason 
to mark it critical.

What goes the the CP and CPS for an AA?

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Mar 2002 14:53:00 +0000

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.

-- 
____________________________________________________________
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

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 7 Mar 2002 09:59:22 -0500

Russ,

An AA CPS would include many of the same things that would be present in a
CA's CPS.  These would include things like: community and applicability for
the ACs issued, statements of liability, issuer/end-entity/relying party
obligations, restrictions on usage of the AC, technical security controls
for the AA's signing key, etc.

In some environments, I believe that an AA might in fact want to make the
certificatePolicies extension critical, especially if there is legal
liability involved.  By making the extension critical it says that relying
parties are required to accept the terms documented in the AA's CPS before
relying on the authorizations granted in the certificate.

Chris

-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 9:21 AM
To: Christopher S. Francis
Cc: Ietf-Pkix
Subject: RE: Attribute Certificate Policy??

Chris:

Russ

---

From: "Housley, Russ" <[email-masked]>
Date: Thu, 07 Mar 2002 10:11:58 -0500

Chris:

Perhaps we can get some of the American Bar Assoc people to comment on the 
CP and CPS issues.  I suspect that we will need to go through an 
educational phase before we get any useful feedaback.  Perhaps they have 
been looking at it and we are just unaware...

Russ

---

From: "Yuriy Dzambasow" <[email-masked]>
Date: Thu, 7 Mar 2002 12:28:40 -0500

Chris:

...snip...

> relying on the authorizations granted in the certificate.

Marking an extension critical has nothing to do with accepting terms in CPs
and CPSs.  Things like relying party agreements address this issue.

Yuriy

...snip...

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 7 Mar 2002 13:15:42 -0500

Yuriy,

Hmm.... You certainly have more experience in this area than I do.  In
actual practice what you say may indeed be the case.  I based my comments on
what I read in X.509.

From X.509 section 8.2.2.6 on the certificate policies extension:

"If the extension is flagged critical, it indicates that the certificate
shall only be used for the purpose, and in accordance with the rules implied
by one of the indicated certificate policies.  The rules of a particular
policy may require the certificate-using system to process the qualifier
value in a particular way.

If the extension is flagged non-critical, use of this extension does not
necessarily constrain use of the certificate to the policies listed.
However, a certificate user may require a particular policy to be present in
order to use the certificate (see 10).  Policy qualifiers may, at the option
of the certificate user, be processed or ignored."

Chris

-----Original Message-----
From: Yuriy Dzambasow [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 12:29 PM
To: Christopher S. Francis; Housley, Russ
Cc: Ietf-Pkix
Subject: RE: Attribute Certificate Policy??

Chris:

...snip...

Yuriy

...snip...

---

From: "Christopher S. Francis" <[email-masked]>
Date: Thu, 7 Mar 2002 13:22:09 -0500

Russ,

I would welcome the opportunity to work with someone at the ABA on this if
you have a contact there.  Let me know how I can help.

Chris
-----Original Message-----
From: Housley, Russ [mailto:[email-masked]]
Sent: Thursday, March 07, 2002 10:12 AM
To: Christopher S. Francis
Cc: [email-masked]; [email-masked]
Subject: Re: Attribute Certificate Policy??

Chris:

Russ

---

From: Roger Younglove <[email-masked]>
Date: Thu, 07 Mar 2002 13:41:31 -0500

I am a member of the Science and Technology Committee of the American Bar 
Assoc. and we are very aware of the CP and CPS liability issues. Having an 
AC CP OID even non-critical would provide the liability protection as long 
as the Relying Party agreement stated the meaning of the OID.  I must 
inform you that I am not a lawyer but I have worked with the best in this 
field over the last five years. Randy Sabett at Cooley is one of them.

>> > >might to the job, but it was apparently profiled out by PKIX.

--------
TTFN
Roger W. Younglove, CISSP
Distinguished Member of Consulting Staff
Lucent Worldwide Services--Information Security
100 Galleria Officentre, Ste. 220
Southfield, MI 48034-8428
Numeric page: 888.935.6755
E-mail page:
[email-masked]
eFax number: 413.425.5368

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 07 Mar 2002 15:53:13 -0500

I just want to point out that X.509 states that the certificatePolicies extension is only to be used in public-key certificates.

The first sentences in section 8 of X.509 state: "The certificate extensions defined in this clause are for use with public-key certificates, unless otherwise stated. Extensions for use with attribute certificates are defined in clause 15." There is nothing in section 8.2.2.6 on the certificatePolicies extension stating that the extension may be used in an attribute certificate, so its use is limited to public-key certificates.

I don't know what mechanisms, if any, are defined in X.509 to provide policy information about attribute certificates, but perhaps someone who is more familiar with that standard can provide some insight.

Dave

---

From: David Chadwick <[email-masked]>
Date: Thu, 07 Mar 2002 22:19:17 +0000

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

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

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 15:51:40 +0100

Russ, Chris and all,

> I am not aware of any work in this area.  You can take the lead.

ETSI is currently performing some preparatory work to identify what is 
specific/different from a Certification Policy.

Thenafter, ETSI will be addressing the topic: "Policy Requirements for
Attribute Authorities" (i.e. the set of practices and procedures that an
Attribute Authority should observe when issuing Attribute Certificates).

Any input on this topic will be appreciated and can be sent directly to me. 
I will take care of them within the ETSI group. 

Denis