Re: [TLS] Next steps for Client Certificate URL

[Russ Housley <housley@xxxxxxxxxxxx>]

This integrity protection is important.  I support the suggestion.

Russ

At 10:13 AM 3/28/2008, Pasi.Eronen@xxxxxxxxx wrote:
>Hi,
>
>We've seen two replies from people who have implemented the Client
>Certificate URL extension (Certicom SSL-C toolkit and IAIK iSaSiLk).
>
>Given that using this feature -- at least on client side -- probably
>requires that the application specifically asks for it (and supplies
>the URL in some API call), I would also guess that most applications
>that use those two libraries don't actually use this particular
>feature.
>
>Given this, would everyone be OK with updating the existing
>client_certificate_url extension so that including the hash is
>mandatory (client MUST send, server MUST NOT accept without hash)?
>This behavior would be independent of the negotiated TLS version.
>
>(One obvious alternative would be to deprecate current
>client_certificate_url, and allocate a new extension number.)
>
>Best regards,
>Pasi
>_______________________________________________
>TLS mailing list
>TLS@xxxxxxxx
>https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls