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. pbaker@xxxxxxxxxxxx 781 245 6996 x227
Attachment:
Phillip Hallam-Baker (E-mail).vcf
Description: Binary data