[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: New Issues, Authorities and Domains
Adding on to my earlier post,
The big problem with PKIX and X.509 is that there is no unified X.500
directory namespace[*] and hence names are inherently subjective and can
only be considered if they are qualified by the issuer's ID which is itself
subjective and so on.
With DNS we have the significant advantage of an existing, widely used and
stable namespace that provides for uniqueness - given good faith. I consider
the PKIX attribute certificate spec to be an example of the horrors we do
not have face. It is an attempt to make a broken namespace model work, it is
not a design to copy if you have a viable namespace.
Phill
[*] Yes I know there are people who claim to have one. Just as there are
people who still believe that the Internet will migrate to the rest of the
OSI stack and a small number of my countrymen who will vote for a party
whose sole manifesto aim is to re-instate the British empire, starting with
the invasion and conquest of France.
Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227
> -----Original Message-----
> From: Jeff Hodges [mailto:jhodges@oblix.com]
> Sent: Thursday, May 24, 2001 8:32 PM
> To: security-services@lists.oasis-open.org
> Subject: Re: New Issues, Authorities and Domains
>
>
> A couple of questions and then a comment/rant.
>
> Hal Lockhart wrote:
> >
> > Here are a couple of issues we should think about.
> >
> > An Assertion is issued by an authority.
> >
> > Assertions may be signed.
> >
> > The name of a subject must be qualified to some domain.
> ^^^^^^^
> Are we implicitly referring to a DNS domain name here? I
> believe so, but we need
> to be explicit, because "domain" is such an
> overloaded/overused/ambiguous word
> (when used without qualification).
>
> > Attributes must be quailfied by a domain as well.
>
> are we imagining each individual attribute-and-value being
> attributed to a
> "domain" or whether an attribute assertion, which is
> ostensibly a bundle of
> attributes-and-values, is just itself attributed to a
> "domain", or both?
>
> > Nigels comments in the last concall suggest that resources
> also need to be
> > qualified by domain.
> >
> [...]
> > 2. Should SAML take any position on the relationship between the 1)
> > Authority, 2) the entity that signed the assertion, and 3)
> the various
> > domains scattered throughout the assertion? The contrary
> view is that is a
> > matter for private arrangement among asserting and relying parties.
>
> overall comment:
>
> I think the SAML specs will need to specify a combination of
> both "views"
> expressed in "2." (above). The specs will have to outline what the
> relationships, and meanings thereof, are between all the
> pieces of info in an
> assertion and the context within which the assertion is
> wielded. The specs will
> also need to describe the opportunities, and lattitude
> thereof, for tuning said
> stuff in particular deployment contexts.
>
> I've spent some time today looking at..
>
> An Internet Attribute Certificate Profile for Authorization
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-06.txt
>
> ..and it seems to me that the authors & reviewers of that doc
> have already
> considered many (if not all) of the same sorts of questions
> we have above,
> including reasoning about use of assertions (aka attribute
> certs (ACs) in
> pkix-ac509prof-06) in context, and the decisions a relying
> party (aka AC
> verifiers) must make based upon the identifying information
> (e.g. holder
> identity, issuer identity, relation of said identities with forms of
> authentication and authentication identities, etc.) in the
> assertion (aka AC).
> Also, it is interesting & worthwhile to note that they've
> made the decision to
> map what we've called a "domain" above (and they call a
> "policyAuthority") to
> certain attributes defined in the context of that doc.
>
> It appears to me that there is much we can learn and/or borrow from
> pkix-ac509prof-06 and thus it'd behoove us to examine it
> carefully. I've listed
> below particular sections that I noticed in my reading.
>
> It'd REALLY help if Stephen Farrell could chime in from his
> perspective as a
> coauthor of pkix-ac509prof-06. I'd guess that he's in the
> best position amongst
> us'ns to proprose which specific techniques/features from it
> are appropriate for
> our consideration in the SAML spec.
>
> JeffH
> -----
>
> Sections from..
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ac509prof-06.txt
> ..that're applicable in a SAML context:
>
> 1. Introduction
> .
> .
> .
> 1.2 Attribute Certificate Distribution ("push" vs. "pull")
> .
> .
> .
>
> +--------------+
> | | Server Acquisition
> | AC issuer +----------------------------+
> | | |
> +--+-----------+ |
> | |
> | Client |
> | Acquisition |
> | |
> +--+-----------+ +--+------------+
> | | AC "push" | |
> | Client +-------------------------+ Server |
> | | (part of app. protocol) | |
> +--+-----------+ +--+------------+
> | |
> | Client | Server
> | Lookup +--------------+ | Lookup
> | | | |
> +---------------+ Repository +---------+
> | |
> +--------------+
>
> Figure 1: AC Exchanges
>
> [hmm, substitute "assertion" for "AC" and this sure looks
> like diagrams that've
> been appearing in various SAML docs. ]
>
> .
> .
> .
>
> 3. Requirements
>
> [seems like "targeting" is pretty darn similar to the
> "audience" notion]
>
> .
> .
> .
> 4.2.2 Holder
>
> [aka "subject"? has specific techniques for relating the AC
> (aka assertion) to
> the holders PKcert if the underlying authn mech used by the
> holder was PK-based]
>
> .
> .
> .
>
> 4.2.3 Issuer
> .
> .
> .
>
> 4.2.5 Serial Number
>
> [it's worth noting that the combo of issuer/sesrialNumber is
> the AC approach to
> an assertionID. ]
>
> .
> .
> .
>
> 4.2.7 Attributes
> .
> .
> .
>
> 4.3.2 AC Targeting
>
> [aka "audiences"]
>
> .
> .
> .
>
> 4.4 Attribute Types
>
> Some of the attribute types defined below make use of the
> IetfAttrSyntax type, also defined below. The reasons for using this
> type are:
>
> 1. It allows a separation between the AC issuer and the attribute
> policy authority.
>
> .
> .
> .
>
> IetfAttrSyntax ::= SEQUENCE {
> "domain" ==> policyAuthority [0] GeneralNames OPTIONAL,
> values SEQUENCE OF CHOICE {
> octets OCTET STRING,
> oid OBJECT IDENTIFIER,
> string UTF8String
> }
> }
> .
> .
> .
>
> 4.4.2 Access Identity
>
> The accessIdentity attribute identifies the AC holder to the
> server/service. [...]
>
>
> This attribute is intended to be used to provide information about
> the AC holder, that can be used by the AC verifier (or a larger
> system of which the AC verifier is a component) to authorize the
> actions of the AC holder within the AC verifier's system.
>
> [this is what's referred to as an "authorization identity" in SASL and
> SASL-based protocols, e.g. LDAP (see RFC 2829/2830); it seems
> to me that we
> don't have an analagous, explicit feature in SAML. Is it
> something to think
> about?]
>
> .
> .
> .
>
> 5. Attribute Certificate Validation
>
> This section describes a basic set of rules that all valid ACs MUST
> satisfy. Some additional checks are also described which AC
> verifiers MAY choose to implement.
>
> [e.g. "attribute assertion validation"]
>
> .
> .
> .
>
> 7.1 Attribute Encryption
>
> [appropos to our (sub)topic of encrypting various sub-chunks
> of an assertion.
> note this only applies to attribute-values, not to the
> holder/issuer fields.
> actual analogous techniques in the SAML world would depend
> upon XMLdsig, of
> course.]
> .
> .
> .
>
> 7.2 Proxying
>
> [anything to think about here?]
> .
> .
> .
>
> 7.3 Use of ObjectDigestInfo
>
> [how to relate the assertion/AC to a public key rather than
> one of the more
> human-palatable identifiers (which're encapsulated in
> GeneralName). Anyting to
> learn/borrow here?]
>
> .
> .
> .
>
> 7.4 AA Controls
>
> During AC validation a relying party has to answer the question: is
> this AC issuer trusted to issue ACs containing this attribute? The
> AAControls PKC extension MAY be used to help answer the question.
>
> .
> .
> .
>
> 8. Security Considerations
>
> [a must-read, but nothing terribly new for those who're PKI-literate]
>
> .
> .
> .
>
> ---
> end
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to:
> security-services-request@lists.oasis-open.org
>
Phillip Hallam-Baker (E-mail).vcf
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC