RE: XACML OID tag?

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

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

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

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.

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