Re: [TLS] the use cases for GSS-based TLS and the plea for

Martin Rex wrote:

<snip>
>
> What I meant (and forgot to add) was "certificate-based credential
> (self-signed when no PKI is used) as a mandatory to implement
> feature for interoperability".
>
> If support of cert-based credentials is a mere MAY, then I am sure
> there will be servers/services where installing or using a PKI
> credential is impossible/defective/unusable, and you cannot complain
> to the vendor because not-supporting it is fully compliant with the spec.
>
> Everyone will be happy when Kerberos can be used cross-organization
> one day.  But until that day, I want to make sure that the customer
> has the working alternative to use PKI when there is a need for it.
>
>   
Its important to remember that _both_ PKI and Kerberos
have cross-realm issues. The main difference is that many
PKI implementations allow the users to disregard the lack
of cross-realm trust (eg a pre-configured trust-anchor).

I know this point has been made before on this thread but
I felt it was important enough to emphasize one more time.

The fact that PKI implementations delegate the trust-
decision to the user at session-establishment-time is
arguably a source of many egregious problems.

This is my way of saying that I agree with Nico that any
arguments based on the fact that Kerberos doesn't have
widely deployed cross-realm are just as pointless as
arguments against PKI because there is no common
trust-root: building federations is a hard problem and
not because we haven't gotten the bits right.

I do believe it is a requirement of any solution in this space
that it be able to gracefully handle the case when the gss
handshake fails (for whatever reason) by falling back to
<whatever>. I think the text used to describe this in the
draft can be improved and I will try to help by offering
constructive comments later on.

       Cheers Leif

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