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

[Rob Stradling <[e-mail]>]

On 26/03/13 14:16, Hannes Tschofenig wrote:
> 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.

> 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?

Yes.

> Ciao
> Hannes
> *Gesendet:* Montag, 18. März 2013 um 16:18 Uhr
> *Von:* "Joseph Salowey (jsalowey)" <[e-mail]>
> *An:* "Rob Stradling" <[e-mail]>
> *Cc:* "<[e-mail]>" <[e-mail]>
> *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
> On Mar 18, 2013, at 6:06 AM, Rob Stradling <[e-mail]> wrote:
>
>  > 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
>  >
>  > _______________________________________________
>  > TLS mailing list
>  > [e-mail]
>  > https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: [phone]
Office Fax: [phone]
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.