Subject: [TLS] cached-info and multiple-ocsp

From: Rob Stradling <[email-masked]>
Date: Mon, 18 Mar 2013 13:06:05 +0000

Hannes, Stefan,

I see that draft-ietf-tls-cached-info-13 expired a couple of days ago.

Does this WG still intend to progress cached-info to RFC status?

On 13/07/12 10:40, Hannes Tschofenig wrote:
<snip>
>> Or, is it your explicit intention to restrict cached-info so that it only supports the "standard" TLS handshake objects (e.g. Certificate, Trusted CAs list).
>> (I can see that such a restriction could help to ensure that client-side code can be implemented entirely within the network layer rather than bleeding into the application layer).
>
> There is no intention to restrict the functionality to certain extensions.
>
> I do, however, believe that new documents should add a description to their document how this document could be used in combination with the TLS cached information extension.
>
> I don't think it makes sense to add text about, for example, draft-pettersen-tls-ext-multiple-ocsp when that work is still in progress.

Since multiple-ocsp is currently in IESG call, it seems likely that 
multiple-ocsp will reach RFC status before cached-info.

Therefore, please could text be added to cached-info to specify its use 
with both of the CertificateStatus extensions (RFC6066 and multiple-ocsp) ?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 18 Mar 2013 15:18:14 +0000

Hi Rob,

We still plan on moving this draft forward.  A revision is in the works.  Please work with the authors to define some candidate text for multi-OCSP.

Thanks,

Joe
On Mar 18, 2013, at 6:06 AM, Rob Stradling <[email-masked]> wrote:

> Since multiple-ocsp is currently in IESG call, it seems likely that multiple-ocsp will reach RFC status before cached-info.
> 
> Therefore, please could text be added to cached-info to specify its use with both of the CertificateStatus extensions (RFC6066 and multiple-ocsp) ?
> 
> -- 
> Rob Stradling
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 26 Mar 2013 15:16:42 +0100 (CET)

Hi Rob,

thanks for your comments. (In all the Salsa mail traffic I overlooked your mail.)

We are indeed working on the update and a most recent snapshot of the work in progress document is available here:

https://github.com/hannestschofenig/tschofenig-ids/blob/master/tls-cached-info/draft-ietf-tls-cached-info-14.txt

Regarding RFC 6066: It includes a number of features but I guess you are interested in allowing to omit send the OCSP response from the server to the client.

Regarding multiple-ocsp: I guess you refer to http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-04 rather than http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp-03.

In draft-ietf-tls-multiple-cert-status-extension-04 I guess you are interested in omitting the multiple OCSP responses (which is an extension to RFC 6066).

Just want to confirm that I am looking at the right documents/functionality.

To ask you further questions have a look at RFC 6066. The OCSP response is defined as follows:

struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
} response;
} CertificateStatus;

opaque OCSPResponse<1..2^24-1>;

Would you expect that the entire "CertificateStatus" message is omitted, which RFC 6066 seems to allow?

Ciao

Hannes

Gesendet: Montag, 18. März 2013 um 16:18 Uhr

Von: "Joseph Salowey (jsalowey)" <[email-masked]>

An: "Rob Stradling" <[email-masked]>

Cc: "<[email-masked]>" <[email-masked]>

Betreff: Re: [TLS] cached-info and multiple-ocsp

Hi Rob,

Thanks,

Joe

TLS mailing list

[email-masked]

---

From: Rob Stradling <[email-masked]>
Date: Tue, 26 Mar 2013 21:40:15 +0000

> Hi Rob,

Hi Hannes.

<snip>
> Regarding RFC 6066: It includes a number of features but I guess you are
> interested in allowing to omit send the OCSP response from the server to
> the client.

Yes.

> Regarding multiple-ocsp: I guess you refer to
> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-04
> rather than
> http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp-03.

Yes.

> In draft-ietf-tls-multiple-cert-status-extension-04 I guess you are
> interested in omitting the multiple OCSP responses (which is an
> extension to RFC 6066).

Yes.

> which RFC 6066 seems to allow?

Yes.

> Ciao
> Hannes
> *Gesendet:* Montag, 18. März 2013 um 16:18 Uhr
> *Von:* "Joseph Salowey (jsalowey)" <[email-masked]>
> *An:* "Rob Stradling" <[email-masked]>
> *Cc:* "<[email-masked]>" <[email-masked]>
> *Betreff:* Re: [TLS] cached-info and multiple-ocsp
> Hi Rob,
>
> We still plan on moving this draft forward. A revision is in the works.
> Please work with the authors to define some candidate text for multi-OCSP.
>
> Thanks,
>
> Joe
>  >>> Or, is it your explicit intention to restrict cached-info so that
> it only supports the "standard" TLS handshake objects (e.g. Certificate,
> Trusted CAs list).
>  >>> (I can see that such a restriction could help to ensure that
> client-side code can be implemented entirely within the network layer
> rather than bleeding into the application layer).
>  >>
>  >> I do, however, believe that new documents should add a description
> to their document how this document could be used in combination with
> the TLS cached information extension.
>  >>
>  >> I don't think it makes sense to add text about, for example,
> draft-pettersen-tls-ext-multiple-ocsp when that work is still in progress.
>  >
>  > Therefore, please could text be added to cached-info to specify its
> use with both of the CertificateStatus extensions (RFC6066 and
> multiple-ocsp) ?
>  >
>  > --
>  > Rob Stradling

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.