RE: [security-services] Trust management and validation viametadata

["Scott Cantor" <cantor.2@osu.edu>]

> Ok, I understand now.  This almost seems like a problem with 
> the XMLSignature spec and not something we would define. 

Well...somebody had to be the first to say it. ;-) Yeah, I agree. I think
KeyInfo should have something like IssuerName/KeyName in addition to
IssuerName/SerialNumber. The latter is too specific, it refers to one
certificate. The former is essentially what I'm suggesting, but the
advantage of rolling it up above at the entity level is just avoiding a lot
of duplication, not to mention supporting multiple CAs easily.

> I agree that SSL is the usual use case for using x509 
> certificate chains - this being one type of indirect trust.  

Well, it doesn't imply that. I would say that SSL can be implemented
*exactly* the same as signed XML. If you support direct key exchange for
signatures, support it for SSL (just do a public key comp on the cert the
server presents).

OTOH, if you support indirect validation for SSL, you should support it for
signed XML too. Both are simply authentication technologies in this context.
I see it as pretty much the same use case. This is essentially what I was
trying to say on the call, that this isn't about holder-of-key, it applies
equally to signed requests or responses.

> x509 cert chains are not limited to just this.  The "Trust 
> Models Guidelines" specifies two types of trust, "Business 
> Agreements" and "Authentication".  I took the authentication 
> trust to mean SSL/PKI as you described it.  If I wanted 
> indirect trust for the "business agreements" trust I could 
> also use PKI/x509 certificate chains to establish this trust. 

Sure, I think business trust is where you map PKI rules into a business
context, and SAML metadata is one example of that. My question is about what
kinds of rules can be expressed there.

> In fact, if I were to implement indirect trust, I would use 
> PKI/x509 simply because I have those tools built here in 
> house (or via OpenSSL).  I have avoided the indirect trust 
> because of the administration issue I mentioned before: Even 
> if the authentication trust and business trust were 
> established indirectly, the administrator still has to 
> manually create configuration for each entity - why not just 
> establish direct trust?   

Well, I'm not going to argue that point too loudly. We're debating exactly
that in our project, that's partly why I'm asking these questions. If nobody
else is implementing anything like this, that sends a message. OTOH, my
sense is that people are using ordinary PKI and trust lists to deal with
SSL, but perhaps not so much with signatures. I think that's inconsistent
for users, and I'm bothered by the fact that the metadata can't express the
configuration rules to apply for both cases. But it can with some pretty
simple extensions.

> (I could only come up with one use case against this 
> thinking: A CA that revokes and reissues certificates on a 
> regular basis) 

Well, it generally pertains to what degree you want to duplicate that
processing in metadata. You can use validUntil and so forth to emulate a lot
of what you do with certs today, there's no doubt about it. But it does have
the feel of reinventing the wheel and rejecting a lot of really long RFCs.
Maybe that's a good thing.

-- Scott