I can see many situations where the information in this is not
sensitive. In fact, in the primary use case, the use mapping
information is not sensitive. An enterprise PKI is used in this
situation, and the TLS extension is used to map the subject name in
the certificate to the host account name.
Russ
At 10:14 AM 2/28/2006, Eric Rescorla wrote:
"Stefan Santesson" <stefans(_at_)microsoft(_dot_)com> writes:
> Adding to Ari's arguments.
> There is one more argument why it would less functional to send the
> mapping data in the extension.
>
> The current draft under last call also includes a negotiation mechanism
> where the client and server can agree on what type of mapping data they
> support.
>
> If the mapping data is sent in the client hello, the client has no clue
> on what data the server needs unless prior knowledge has been
> established. It must then send all types of mapping data that it
> believes the server might need. This is less desirable than sending just
> the type of data the server explicitly has stated that it prefers out of
> the types the client has stated that it supports.
>
> While it would be technically possible to implement the same solution
> along with Eric's alternative suggestions, I don't think it has been
> demonstrated that it would provide any significant advantages.
I don't want to get into a long point-by-point here. Suffice to say
that I don't agree with either this analyis or Ari's. It would,
as I noted, have the advantage of actually applying confidentiality
for data you claim is sensitive while avoiding the need to declare
a new code point. I consider both of these to be significant advantages.
-Ekr
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf