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


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



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


Powered by eList eXpress LLC