With regards to the IPR disclosure available at
https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=1036,
the authors of that draft believe that there is no claims to do with
regards to the patent; each of these two documents describes its own
way to negotiate the identity protection during the TLS negotiation
(the draft enables that by defining a set of specific TLS Cipher
Suites, whereas the patent proposes specifying a new TLS extension
for that purpose).
Computing a key from the premaster secret and the random values using
the PRF function isn't patentable, since this is specified by TLS and
SSL documents. From the authors' point of view, the way for the
client and the server to negotiate the identity protection feature is
the only part to be patentable. This is why the authors estimated
that no IPR disclosure is required. On the other hand, the draft
authors - one of them is also a co-inventor of the patent - already
discussed of this situation with the involved entity during the draft
revision process and explained their point of view regarding the
relationship between the draft - which is not aiming at Standards
Track - and the patent. Moreover, they proposed sending at that time
an IPR disclosure, if needed.
In any case, the way for encrypting the certificate during key
exchange protocols (i.e., TLS) is not new and had been said many
times before the patent publication date. Below some non-exclusive
publications that enable identity protection by asymmetrically or
symmetrically encrypting the certificate using a secret key computed
during the key exchange establishment. Some of them compute the key
to encrypt the certificate, in the same way as the patent proposes
today.
1- Adding client identity protection to TLS (2000): available at
http://www.imc.org/ietf-tls/mail-archive/msg02004.html: It
consists of sending the ChangeCipherSpec message before the
Certificate and the CertificateVerify messages and after the
ClientKeyExchange message. The ChangeCipherSpec message is
sent to notify the receiving party that subsequent messages
will be protected under the cipher suite and keys negotiated
during the TLS Handshake. The keys are computed by applying
the PRF on the premaster secret and on the random values
generated by both the client and the server, as described in
TLS and SSL documents.
2- Beller-Yacobi protocol (1997): described in "Handbook of
applied cryptography", CRC PRESS SERIES ON DISCRETE
MATHEMATICES AND ITS APPLICATIONS, BOXA RATON, FL, CRC PRESS,
US, 1997, pages 37- 39, 428, XP002204463, ISBN 0-8493-8523-7.
3- Aura T, Ellison C, "Privacy and Accountability in Certificate
Systems", Research reports 61, [online], April 2000,
htpp://www.citeseer.ist.psu.edu/cs. This document describes an
authentication mechanism in which the client certificate is
sent encrypted.
4- Samfat D, et. al., "Untraceability in Mobile Network", Mobicom
proceeding, 1995, pages 26-36.
5- US Patent 6189098 - Client/server protocol for proving
authenticity (2001), Figures 3a, 3b. This patent also
describes a way to symmetrically encrypt the certificate by
its owner before sending it over the wire.
6- http://www.niksula.cs.hut.fi/~sjsavola/SoN/essay.html (1999),
Identity Protection Exchange: The Identity Protection Exchange
is designed to separate the Key Exchange information from the
identity and authentication related information. A common
share secret can be established before identification and
authentication related information is exchanged and encryption
provides protection of the communicating identities.
7- Just Fast Keying (JFKi, 2003),
http://people.csail.mit.edu/canetti/materials/jfk.pdf,
computes a secret key from DH exchange and encrypts the
certificate with this key.
8- The SIGMA protocol (2001), idem for JFK.
9- http://pastel.paristech.org/1168/01/these_ibrahim_02-04-05.pdf
(French document, 2004), see Chapter 6. | 
datatracker.ietf.org