OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [xacml] Proposed resolution to PM-1-02: Post-Conditions


Title: RE: [xacml] Proposed resolution to PM-1-02: Post-Conditions

Polar - The critical flag in X.509 and PKIX has been a real source of trouble, primarily because (in the early days) its semantics were poorly understood.  It will be important for us to fully describe what a PEP is required to do with an obligation.  We'll have to be careful with our choice of words, but I think the sense is that a PEP may knowingly disregard an obligation.  But, it SHALL NOT disregard an obligation that it does not recognize.  In practice, a PAP SHOULD only include obligations that it has good reason to believe will be recognized by the PEPs it expects to rely on its decisions.

All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183


-----Original Message-----
From: Polar Humenn [mailto:polar@syr.edu]
Sent: Tuesday, March 26, 2002 10:38 AM
To: Anne Anderson
Cc: bill parducci; XACML TC
Subject: Re: [xacml] Proposed resolution to PM-1-02: Post-Conditions


On Tue, 26 Mar 2002, Anne Anderson wrote:

> This issue seems very similar to the IETF PKIX Working Group
> handling of "critical" extensions in public key certificates.
> The PKIX specs say:
>
>    "A certificate using system MUST reject the certificate if it
>    encounters a critical extension it does not recognize;..."
>
> Would the word "recognize", rather than "understand", help?

Yes, but there is a well specified process here of what is meant by
"recognized". The extension is labled with an OID, which specifies its
exact encoding and (maybe) its semantics.

In general, for backward compatibility, the relying party (RP) is free to
ignore any extensions it doesn't (yet) know about.  However, if the
"critical" bit is "on" for that extension, the RP must reject the
certificate during its validation phase.

This procedure, forces you to update the RP to know about those
extensions, by rippling failures across your PKI'ed applications. Once
updated, you can still ignore the bloody thing.

It's sort of the like the Microsoft model of getting you to buy a new
version of Word every year or so, because somebody sends you a document in
their new Word format. (and when you finally break down, buy it, and get
it open, and it's a invite to a marketing seminar on time shares in the
Bayuou swamps. :)

In practice, however, I don't have a feel for how much this feature is
really used. Perhaps the Entrust guys can comment?

Cheers,
-Polar

> Anne
>
> On 25 March, bill parducci writes: Re: [xacml] Proposed resolution to PM-1-02: Post-Conditions
>  > i would suggest that this is 'practical syntactic comprehension'. for
>  > example if the obligation states 'permit, but encode 3DES', the PEP
>  > needs to have an internally actionable method that maps to the term
>  > 'encode' and that method must support 3DES. if not, an ERROR condition
>  > arises (and i would assume a DENY would follow).
>  >
>  > b
>  >
>  > Polar Humenn wrote:
>  >
>  > > On Fri, 22 Mar 2002, Michiharu Kudoh wrote:
>  > >
>  > >
>  > >
>  > >>If the PEP does not understand an obligation, the PEP should deny
>  > >>access.
>  > >>
>  > >
>  > > I'm sorry. I really have a problem with this statement. "What is the
>  > > specification of "understand"?
>  > >
>  > > -Polar
>  > >
>  > >
>  > > ----------------------------------------------------------------
>  > > To subscribe or unsubscribe from this elist use the subscription
>  > > manager: <http://lists.oasis-open.org/ob/adm.pl>
>  > >
>  >
>  >
>  >
>  > ----------------------------------------------------------------
>  > To subscribe or unsubscribe from this elist use the subscription
>  > manager: <http://lists.oasis-open.org/ob/adm.pl>
>  >
>
> --
> Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> Sun Microsystems Laboratories
> 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> Burlington, MA 01803-0902 USA  Fax: 781/442-1692
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC