[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] Implementation survey: Client Certificate URL extension
From:       "Dieter Bratko" <Dieter.Bratko () iaik ! tugraz ! at>
Date:       2008-03-18 16:48:16
Message-ID: 02e801c88917$dd301c70$6d981b81 () iaik ! tugraz ! at
[Download RAW message or body]

Hello,

our IAIK iSaSiLk Java SSL/TLS library supports the 
client_certificate_url extension (client and server side).
Including the hash is optional. 

Regards,
Dieter

---------
Dieter Bratko, <mailto:Dieter.Bratko@iaik.tugraz.at>
SIC/IAIK - Graz University of Technology
IAIK, Inffeldgasse 16a, 8010 Graz, Austria, http://jce.iaik.tugraz.at/


----- Original Message ----- 
From: Pasi.Eronen@nokia.com 
To: tls@ietf.org 
Sent: Tuesday, March 18, 2008 12:39 PM
Subject: [TLS] Implementation survey: Client Certificate URL extension


Hi,

We currently have two open technical issues for 4366bis,
both related to the Client Certificate URL extension (#45 
about making the hash mandatory; and #46 on how to do
algorithm agility).

The proposal in IETF71 was to make including the hash a MUST
(regardless of TLS version number), and handle algorithm agility 
with a new extension number later (if it turns out something
actually needs to be done).

However, making the hash mandatory has some potential for interop
problems (if there are old implementations which don't send it).

If you have implemented, or have heard of someone implementing, 
the client_certificate_url extension, please send email.  
Additional details (is this a client, server, or both; do you 
send the hash, etc.) are welcome but not required.

Best regards,
Pasi
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


[prev in list] [next in list] [prev in thread] [next in thread]