RE: [TLS] Please discuss: draft-housley-evidence-extns-00<

all i can really do to respond to that, apart from arguing too recent history, is to cite my actual operational choices today.

i have about 100 users a second doing federated logon, using saml blob exchanged between the two endpoint. Today, i sign/verify the saml using xmldig, as it makes an evidentiary record. I could configure the servers to use tls to exchange the same saml blob, unsigned. But today i lose the evidentiary semantics that the xmldig handshake adds to my audit trail.

if i had tls evidence, i could use the tls variant binding, passing the saml blob in a ticket (peter's solution, today, leveraging existing stds) or in a tls evidence exchange of some form, tomorrow.

-----Original Message-----
From:	"Martin Rex" <martin.rex@sap.com>
Sent:	Monday, January 29, 2007 8:03 PM
To:	"home_pw@msn.com" <home_pw@msn.com>
Cc:	"martin.rex@sap.com" <martin.rex@sap.com>, "tls@ietf.org" <tls@ietf.org>
Subject:	Re: [TLS] Please discuss: draft-housley-evidence-extns-00<

home_pw@msn.com wrote:
> 
> We cannot stop the experimenting. And should not try. Yes, 
> there are lots of hidden agendas. What's new? They didn't 
> stop us transforming PEM into the full spectrum key 
> management world(s) that SSL now enjoys, did they?

But that is very far from what really happened.

The IETF didn't transform PEM into PKI.  SPKI was an IETF approach,
but it seemed to have died down (OpenPGP and SSH do their own formats).

What happened was, that after the OSI communication protocols had
failed miserably in the marketplace, many of the participants of
the OSI/ISO standards organization started staffing IETF working
groups and with pretty complete Proposals (X.509, SSL, S/Mime)
and tried to prevent the IETF from killing further of their existing
work as well.

A lot of stuff in PKI X.509 is complex bloat and burden, and impairs
interoperability for political or business model purposes, and not
for its technical merit.

One of the cumbersome legacy problems resulting from this approach are
the X.500 distinguished names, which are equally unusable for humans
and software.

The XMLsig guys seemed to have realized that problem too far down the road
(stringified distinguished names may be pretty to look at, but close to a
dead-end road for futher PKI processing), so the SubjectKeyIdentifiers
had to be invented and retrofitted later.

-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls