Subject: RE: XACML OID tag?

From: Hal Lockhart <[email-masked]>
Date: Wed, 12 Sep 2001 17:34:48 -0400

Bob Jueneman wrote:
> This is join to sound like heresy, but has anyone defined an 
> OID tag for XACML, so that an XACML string could be included 
> in a X.509 certificate?

...

> Toolkits which would provide enterprises to issue their own 
> certificates have so far failed to take off to any 
> significant degree

...

> One of the reasons, I believe, is that the neither the public 
> TTPs nor the toolkit vendors have so far adequately addressed 
> the important issue of providing a cross-enterprise Privilege 
> Management Infrastructure solution.  And now that they are 
> feeling a very significant financial pinch, they may not have 
> the wherewithal to solve that problem.

Perhaps you are simply looking for an OID to put arbitrary XML in a cert, so
this response will be overkill, but I believe your message implies a lack of
understanding of the XML security work currently going on at OASIS (SAML and
XACML)

XACML is defining the means to express Access Control Policies. I don't
really see what the semantics of an access control policy in the middle of a
cert would be.

Perhaps you are thinking of SAML. SAML has Attribute Assertions which are
almost like Attribute Certs. Also it has Authentication Assertions which
seem mostly useful in non-PKI environment. Finally there are Authorization
Decision Assertions, which are likely to be quite specific to a resource and
short lived. Again it is not clear what putting one in a cert would signify
exactly.

Of course all can be signed using XMLdsig and thus be consumers of PKIX
mechanisms. But I am unclear what sort of a use case you have in mind.

> Maybe it's just the religion of the week (XML) creating an 
> evangelistic fervor, but that's where the buzz seems to be 
> these days.  And I'd rather drop some XACML into an X.509 
> certificate and make use of the existing tools, rather than 
> create everything from scratch.  And yes, if X.509 attribute 
> certificates had been better thought out and/or more widely 
> implemented, maybe this wouldn't be necessary. And if pigs 
> could whistle and cows could fly, then the world would be a 
> much different place.

If you believe X.509 Attribute Certs are broken (as opposed to unused) I
would like to hear why, since SAML Attribute Assertions are very similar. On
the other hand, SAML has a lot of other machinery, so perhaps we have
already addressed your concerns.

I understand the buzz concern, but there is actually very little overlap
between the functional capabilities of PKIX and the OASIS security work.

> Anyway, does anyone have such an OID and a suggested way to 
> use it?  If not, I guess I'll explore rolling my own, unless 
> someone else wants to join in the fun.

Before you design something, I suggest you propose a usecase or some
requirements or something.

Regards,

Hal

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 12 Sep 2001 16:57:58 -0600

I very well may be confused ― it certainly wouldn't be the first time!
 
The last time I looked at SAML, it had "entitlements", but they were an unspecified bag of bits, and I was under the impression that the intent was for those entitlements to eventually be expressed in XACML.  Since XACML hasn't published anything yet, at least to my understanding, I done';t know what it would contain. But if you are correct, and XACML is a way of expressing an access control POLICY, rather than granting a particular user some particular right or capability, then you are right ― including XACML in a certificate wouldn't make much sense. So perhaps I need to include the SAML Attribute Assertions instead.
 
In any case, I'm not quite ready to buy into the necessity of recoding all of the infrastructure in XML ― it just seems like too big a task to bite off right now, with less than a solid business case justification (hype doesn't count).
 
So what I was hoping to do was to come half way to the mountain, and play around with some XML to learn more about the possible problems ― get my feet wet, so to speak.
 
Since we have existing support for X.509-based authentication to eDirectory and other applications, putting some XML attributes in the certificate would take advantage of that infrastructure, while using XML for the attribute assertion would presumably provide a mechanism for supporting extranet authentication, assuming the parties agree as to both the name of the attribute (easy), and the precise semantics (much harder, generally).

I don't really want to have to implement XMLdsig at this point in time, as I don't see what advantages it provides over existing IETF-standardized signature mechanisms.  If I can simply drop the attribute assertions into an X.509 certificate issued by the organization that is attesting to the attributes (and the user's identity, for what that's worth), then I don't have to do anything extra.  XMLdsig seems like politically correct overkill, and I can't afford that.

I do believe that X.509 attribute certificates are broken, as well as unused.  The last time we went through some of those issues on the PKIX list, it became apparent that controlling the delegation of attributes through a chain of attribute certs was even more difficult than controlling identity assertions via policy constraints, name subordination, etc.  As a result, the only uses that I have heard be suggested for attribute certs used only a one-level deep model, so that selecting the root validates all of the certificates under that root.  To me, that doesn't seem to scale very well.
 
This same issue of the control of delegation concerns me even more in SAML, because in at least some of the use cases, every enterprise effectively becomes their own identity and attribute authority.  Given the experience we have so far with X.509 certificates, there isn't much evidence to suggest that most enterprises will do a very good job of this.  Even some of the best public CAs have trouble with this, as witness the bogus Microsoft code signing certificate.
 
To my way of thinking, it is extremely important that every entity in the delegation chain be able to control delegation of any particular attribute, both up and down the chain.  The top level root and some subordinate CA may decide that they don't want to delegate some particular authority to a sub-CA, and in that case it shouldn't matter what that sub-CA claims ― the relying party should be able to tell quickly and easily that that right wasn't granted.  On the other hand, the relying party may decide that he doesn't want to trust some higher level CA or even some root CA with respect to some particular attribute.  If Osama ben Laden grants me the right to access the CIA's mainframe in a signed XML entitlement, I doubt that the CIA will be very impressed.
 
It seems to me that if the only controls you have in this space is certificate chaining, then you are forced into an all or nothing situation.  You either have to establish a unique root and a unique certificate chain for each individual attribute , or you have to lump several attributes into an indistinguishable group of capabilities and either accept them all or reject them all.  both alternatives seem unacceptable.
 
ON the other hand, a bit-oriented MAC label can solve these problem easily ― you just AND all of the capabilities together, from the top to the bottom of the chain, and see what you have when you get through.  I'll be happy to send you the URL of a document that specifies how all this can be done if you are interested.  
 
Using XML names rather than bits may make this process a little bit more user-friendly, although it also tends to make negation somewhat harder.  I'm sure that there are other problems, and I'm equally sure that I don't understand them all.
 
In any case, thanks for the education, and I'll go do some more reading.

Bob

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Sep 2001 08:37:48 -0700

Some responses to Bob's points and others.

1) There is no OID and if there was I have no idea what the semantics of the
OID would be.

2) The way to link a SAML assertion to a certificate is to use the KeyInfo
element of the SubjectConfirmation field to identify the authentication
credentials of the subject to which the assertion is bound. This may be
either by the Certificate itself, by the certificate serial and issuer or by
the public key parameters.

3) Although SAML attribute assertions are similar to X509.v3 attribute
certificates there are significant differences in the models. With attribute
certificates the model is of issuing static pieces of data that have long
validity intervals (days at least). The attribute certificates require the
issuer to establish parallel identity and attribute certification
hierarchies. The idea that end entity clients would ever implement cross
certification is bogus. The idea that end entities are going to implement a
functioning bifurcated authentication and attribute cross certified
heterarchy with separate roots of trust is bogus with knobs on.

4) For the specific SAML uses of attribute assertions it is the PDP that
performs the attribute processing and not the enforcement point (i.e. the
device hooking into the system). The important upshot of this is that it is
not necessary to standardize implementation of policy languages in the end
entity devices.

5) SAML does not provide the status management functions of X.509 but the
SAML framework may be readilly extended to support them, not least because
XTASS, the original assertion framework on which SAML is based supported an
assertion status mechanism (tier 4).

If an attribute statement is simply a statement about a subject the chances
are that a realtime OCSP type system will be much more satisfactory than a
static certificate based system. The number of accesses within the validity
interval, the sparseness of the data, etc. is simply to small to make
certificate issue worthwhile. 

The intended use for the tier 4 meta-assertion scheme is to manage
assertions that map to negotiable financial instruments.

6) I agree with Hal on the points he made, however remember that the SAML
working group has a very narrow scope. The assertion framework on which SAML
is based was designed as a very general purpose vehicle.

7) We examnined the use of XER encoding at length for a full 6 minutes early
in the design of XTASS/XKMS/SAML/XKASS/XTAML when it was all called TAXI
(Trust Assertion XML Infrastructure). It would be a completely worthless
exercise. There is no intrinsic value in the XML syntax over the X.509 great
enough to outweigh the fact that there is a massive X.509v3/BER installed
base. There is no value therefore in introducing a new PKI syntax unless the
semantics are also changed to allow uses that were not possible before.

8) The idea of canonicalization is broken. It was broken in DER it is still
broken in XML Signature. If you want to be able to check signatures put the
responsibility on the infrastructure not to mess with the bits. The minute
you try to support applications that slightly mangle data you lose big. The
ability to burst a certificate into components and put it in a directory
*and then delete the original* is bogus, was bogus and will remain bogus.

If digital signatures had been implemented in the very first email systems
then gateways would never have got into the idiotic charater set and line
wrapping transformations that break so many messages. That task should
always have been performed by the end client. The reason IP works and many
competitors do not, is that unlike other schemes IP does not mangle the
contents of each packet in transit.

9) If you really wanted to you could use X.509 as a signature envelope for
SAML assertions instead of XML DigSig (which is by the way a joint IETF-W3C
WG). But CMS would appear to be a much easier and simpler solution.
Alternatively you could profile XML-Dig sig, use the minimal c14n etc. to
make implementation trivial.

	Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[email-masked]
781 245 6996 x227

---

From: "Bob Jueneman" <[email-masked]>
Date: Thu, 13 Sep 2001 11:12:38 -0600

Phillip,

Marshall Rose, back in the NADF days, used to have T-shirts with a picture of a pig with a wooden leg. There was a long-winded story that went with it about how marvelous this life-saving pig was, and the punch line was, "You wouldn't want to eat such a marvelous pig all at once, would you?", referring to the slow deployment of X.500.

That's sort of the way I feel about SAML and all of the X-everything alphabet soup that the standards of the month club is serving up these days (or at least promising to) ― I'm not sure that I want to eat that pig all at once.

I was thinking about including something like a SAML assertion (which I had incorrectly understood would be coded in XACML) within an X.509 certificate in order to at least try out some of the XML concepts and compare them to the bit-oriented MAC label approach we have described and partially implemented.  Including them within an X.509 certificate might eventually end up being useful in its own right, or it might be merely a testing crutch or kludge.

I do agree completely with your eloquent and highly descriptive "bogus with knobs on" characterization of a parallel, cross-certified identity and authorization certificate structure, with multiple trust roots for each attribute ― such a concept is completely infeasible, and not worth even thinking about.

Having said that, that doesn't ipso facto mean that the SAML approach is necessarily better ― it may be or it may not be, and it may even suffer from some of the same problems. That's what I wanted to evaluate before jumping on the band wagon.

I suppose that it greatly depends on the use model that you have in mind.  If you have a retail model in mind, where the user comes to one merchant (or a portal), say 4x4Tires.com, and is then redirected to BigWheels.com that sells stronger wheels for those guys that like to play in the mud, then a very limited duration attribute credential that gives the customer a 10% discount and maybe some kind of a kickback to the referring merchant is appropriate.

On the other hand, if the parts guy at JeepsRUs wants to order some wheels from Daimler-Chrysler, then it isn't at all obvious that he needs to first go to some local SAML server and then be redirected to Daimler with a 5 minute credential in hand.  He could have been issued a semi-permanent certificate/credential containing the necessary entitlements by the dealer (and oh by the way an organizational person identity vouched for by the same dealer), and the dealer's certificate could have either been issued by Daimler or cross-certified by them.  In either case, the duration of that certificate might well last for a year or more, and it isn't at all obvious that an real-time OCSP mechanism is necessary to validate that certificate over and over again.  Cached CRLs would do just fine.

I realize that that scenario doesn't fit the business model of current TTP CAs very well, and at the same time I observe that the do it yourself model of CA toolkits isn't selling very well in the marketplace either.  So I don't know whether that model is really feasible either ― it certainly hasn't done all that well to date.

But given the general lack of success (i.e., revenue) in this arena to date, I certainly don't want to launch yet another huge effort on the basis of "if we build it they will come" hope and hype.

I agree with the rest of your comments.

Bob

>>> "Hallam-Baker, Phillip" <[email-masked]> 09/13/01 09:37AM >>>

	Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 13 Sep 2001 10:33:47 -0700

> I realize that that scenario doesn't fit the business model 
> of current TTP CAs very well, and at the same time I observe 
> that the do it yourself model of CA toolkits isn't selling 
> very well in the marketplace either.  So I don't know whether 
> that model is really feasible either ? it certainly hasn't 
> done all that well to date.

The key to any complex system is where you put the complexity.

The idea of XKMS and SAML is to put the complexity where it is easily
accessible for maintenance as necessary. The unfortunate side effect of the
'end to end' theology is that too much complexity got embedded into the end
points which cannot be maintained reliably on a day to day basis and once
deployed may be in service for years or decades.

To make an analogy, the XKMS approach is equivalent to putting the access
panel to the compressor on the side of the hot tub, the PKIX approach is
putting the access panel underneath it.

The disadvantage of the SAML/XKMS approach is that it lowers the barrier to
entry for the end point but transfers that cost to the infrastructure. Ten
years ago no party had the necessary capital to invest in the infrastructure
required. Today much of the physical infrastructure is a sunk cost.

To make another analogy, the first electricity companies sold package
generators to individual factories, that model was quickly replaced by the
model in which one large paower station served an entire town and the
capital and maintenance costs were distributed over many more users gaining
economies of scale.

	Phill

---

From: Carlisle Adams <[email-masked]>
Date: Thu, 13 Sep 2001 16:49:32 -0400

Hi Bob, Phill,

Forgive me if this sounds a bit harsh, but I do wish that some of the
critics of the attribute certificate portion of the X.509 specification were
more familiar with its contents.

I have no real interest in entering into a long thread on this topic, but I
have embedded some responses below (just for the sake of clarification).

Carlisle.

> ----------
> From: 	Bob Jueneman[SMTP:[email-masked]]
> Sent: 	Thursday, September 13, 2001 1:12 PM
> To: 	[email-masked]; [email-masked]
> Subject: 	RE: XACML OID tag?
> 
> Phillip,
 
(...some text deleted...)

> I do agree completely with your eloquent and highly descriptive "bogus
> with knobs on" characterization of a parallel, cross-certified identity
> and authorization certificate structure, with multiple trust roots for
> each attribute ― such a concept is completely infeasible, and not worth
> even thinking about.
 
(...more text deleted...)

> Some responses to Bob's points and others.
 
(...even more text deleted...)

> validity intervals (days at least). 
 
No.  The fact that a validity period is present in the certificate does not
mean that the interval must be long ("days at least").  A validity period
can obviously be for any length of time (even seconds).  SAML assertions
also have validity periods.  In both X.509 and SAML the model is flexible
and accommodates long-lived and short-lived ACs/assertions.

> The attribute certificates require the
> hierarchies. 
 
No.  The X.509 AC model allows (but does not require) parallel certification
"hierarchies" (I use quotes because there need not be a multi-level
hierarchy either; a single authority directly issuing end entity
certificates is consistent with both the model and the syntax of X.509).
The SAML model also allows (but does not require) parallel assertion
"hierarchies" -- the authentication authority and the attribute authority
may or may not be the same entity.

> The idea that end entity clients would ever implement cross
> certification is bogus. 
 
What do you mean by "implement"?  By definition, end entities never actually
cross-certify (only authorities do that), so perhaps you simply mean that
end entities should never have to understand cross-certification.  If so,
fair enough.  But, like SAML, nothing in X.509 forces end entities to
understand cross-certification.  The authorities in both models can
cross-certify or not (depending on the trust model in use in a given
environment), but the existence of protocols such as OCSP and SCVP are proof
enough that path validation (including cross-certification, if present) can
be delegated to a third party, freeing the end entity from the need to
understand any of these details.

> The idea that end entities are going to implement a
 
See my previous response (with knobs on).  The presence of
cross-certification (either on the identity side or the attribute/privilege
side) depends on the choice of trust model.  However, this can be
independent from whether or not end entities understand such details and are
able to properly process such chains.

> not necessary to standardize implementation of policy languages in the end
 
X.509 ACs can be implemented using exactly the same model.  I don't
understand you point here.

> static certificate based system. 
> 
Note that "realtime OCSP" systems today are built specifically around the
concept of a "static certificate-based system".  OCSP doesn't replace
certificates; it replaces CRLs (at least from the end entity's point of
view).  I don't understand your sentence here.

> The number of accesses within the validity
 
Fine -- as long as something else is there to provide the integrity and
authenticity.  Relying on the existence (and use!) of underlying secure
transport can be risky.  There's no guarantee that it's there, and if it is
there, there's no guarantee that applications will actually use it
correctly.  So, X.509 took the safer route and mandated certificates (i.e.,
authority signatures over the payload) for its identity and privilege
information.  SAML (so far) has made this optional and compensated by saying
that the potential risks will be discussed in the Bindings or Security
Considerations sections.  Maybe this will turn out to be far-sighted and
wise, but maybe it will just come back to bite us.  Who knows?

The bottom line is that there is almost no difference (especially in overall
model) between an X.509 attribute certificate and a SAML attribute
assertion.  The way they are used, the requirements on the end entity, the
presence or absence of cross-certification, etc., can all be identical in
any given environment or deployment.  X.509 is perhaps more general in that
its syntax and descriptive text explicitly discuss how delegation and
cross-certification can be accomplished, but these are no more mandated in
X.509 than they are in SAML.

Carlisle.