Cert Cache adopted as TLS standards work
Today (March 26) at the IETF 74 conference, the TLS working group decided to adopt the certificate cache work with the intention to develop this to a new TLS standard. The decision was made after my presentation of the certcache proposal at the TLS working group.
The basic idea behind this proposal can be found in this blog article.
The first draft (draft-santesson-tls-certcache-00) is available here
TLS Meeting agenda and presentations
It was decided that the presented problem is worth solving and that the current document is a good starting point. Eric Rescorla proposed that we should make the approach a bit more generic to allow the client to cache also other data from previous handshakes.
A major issue has been the question whether to include hash algorithm agility (by adding an algorithm identifier) to allow the client to use any hash algorithm, or if it would be better for interoperability to just require use of SHA-1. The meeting decided in favour of allowing hash agility. There main reason is to allow any possible security implication caused by the fact that this hash is going to be part of calculating the TLS finished message.
Quynh Dang from National Institute of Standards (NIST) has agreed to help me as co-author of this new standard. A new draft will be posted as long as we have updated with all comments received during this IETF.
The basic idea behind this proposal can be found in this blog article.
The first draft (draft-santesson-tls-certcache-00) is available here
TLS Meeting agenda and presentations
It was decided that the presented problem is worth solving and that the current document is a good starting point. Eric Rescorla proposed that we should make the approach a bit more generic to allow the client to cache also other data from previous handshakes.
A major issue has been the question whether to include hash algorithm agility (by adding an algorithm identifier) to allow the client to use any hash algorithm, or if it would be better for interoperability to just require use of SHA-1. The meeting decided in favour of allowing hash agility. There main reason is to allow any possible security implication caused by the fact that this hash is going to be part of calculating the TLS finished message.
Quynh Dang from National Institute of Standards (NIST) has agreed to help me as co-author of this new standard. A new draft will be posted as long as we have updated with all comments received during this IETF.