Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt

From: [email-masked]
Date: Wed, 09 May 2012 08:35:13 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title           : The TLS Multiple Certificate Status Request Extension
	Author(s)       : Yngve N. Pettersen
	Filename        : draft-ietf-tls-multiple-cert-status-extension-00.txt
	Pages           : 9
	Date            : 2012-05-09

   This document defines the Transport Layer Security (TLS) Certificate
   Status Version 2 Extension to allow clients to specify and support
   multiple certificate status methods.  Also defined is a new method
   based on the Online Certificate Status Protocol (OCSP) that servers
   can use to provide status information not just about the server's own
   certificate, but also the status of intermediate certificates in the
   chain.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-multiple-cert-status-extension-00.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extension/

---

From: Sean Turner <[email-masked]>
Date: Sat, 26 May 2012 16:08:06 -0400

Yngve,

Thanks for getting this posted so quickly.

A lot of my comments are about supporting both OCSP and SCVP (OCSP being 
the MTI).  I think it would be good to future proof this spec a bit, 
because I can see somebody coming down the trail later asking for it.

0) Move the requirements terminology to s1.1.  The RFC editor will move 
it so you might as well do it now.

1) abstract:

OLD:

  Also defined is a new method
  based on the Online Certificate Status Protocol (OCSP) that servers
  can use to provide status information not just about the server's own
  certificate, but also the status of intermediate certificates in the
  chain.

NEW:

  Also defined is a new method based that servers
  can use to provide status information (i.e., Online Certificate Status
  Protocol and Server-Based Certificate Validation Protocol) not just
  about the server's own certificate, but also the status of
  intermediate certificates in the chain.

2) s1: r/such as CRLs,/such as Certificate Revocation Lists (CRLs),

3) s1: Introduce OCSP and SCVP

OLD:

   Second, the current format of the extension and
   requirements in the TLS protocol prevents a client from offering the
   server multiple status methods.

NEW:

   Second, the current format of the extension and
   requirements in the TLS protocol prevents a client from
   offering the server multiple status methods; there are two
   defined the Online Certificate Status Protocol (OCSP)
   [RFC2560] and the Server-Based Certificate Validation
   Protocol [RFC5055].

4) s1: contains the following:

  Many Certification Authorities are now issuing intermediate CA
  certificates that not only specify a CRL Distribution Point
  [RFC5280], but also a URL for OCSP [RFC2560] Certificate Status
  requests.

I think it makes sense to say where they're putting the OCSP URL:

  Many CAs issue intermediate CA certificates that not
  only specify the publication point for their CRLs in CRL
  Distribution Point [RFC5280], but also specify a URL for their
  OCSP server in Authority Information Access [RFC5280].

5) s1: I'd tweak the following a bit:

OLD:

   Given that client-cached CRLs are frequently out of date,
   using OCSP to access up-to-date status information about
   intermediate CA certificates will be of great benefit to
   clients.

NEW:

   Given that client-cached CRLs are frequently out of date,
   clients would benefit from using OCSP to access up-to-date
   status information about intermediate CA certificates.

6) s1: Some more tweaking:

OLD:

  For these reasons, it will be beneficial to use the TLS server to
  provide the certificate status information not just for the server
  certificate, but also for the intermediate CA certificates. This
  will ...

NEW:

  Clients will benefit from the TLS server providing certificate
  status information regardless of type not just for the server
  certificate but also for the intermediate CA certificates.  Combining
  the status checks in to one extension will ...

7) s1: Starting to like the idea of not using must if you don't have to:

r/it must be possible for clients to/client need to

8) s1: r/TLS Protocol/TLS Protocol [RFC5246]
        r/PKIX infrastructure/PKIX infrastructure [RFC5280]
        r/by using/using

9) s1: (no action required) I think the introduction will be helpful 
during subsequent directorate/IESG reviews because it nicely explains 
why the WG thinks the extension is needed.

10) s2.2: I think we can drop the "like":

r/certificate status protocol like OCSP/certificate status protocol 
(i.e., OCSP and SCVP)

11) s2.2: Add SCVP ...

OLD:

  struct {
      CertificateStatusType status_type;
      uint16 request_length; /* Length of request field in bytes */
      select (status_type) {
        case ocsp: OCSPStatusRequest;
        case ocsp_multi: OCSPStatusRequest;
      } request;
    } CertificateStatusRequestItem;

NEW:

  struct {
    CertificateStatusType status_type;
    uint16 request_length; /* Length of request field in bytes */
    select (status_type) {
      case ocsp: OCSPStatusRequest;
      case ocsp_multi: OCSPStatusRequest;
      case scvp: SCVPStatus Request;
    } request;
  } CertificateStatusRequestItem;

SCVP will allow you to send multiple certs in one request so I don't 
think there's need for scvp_multi - unless we want to restrict scvp to 
just be one and have a scvp_multi for more than one.

OLD:

   enum { ocsp(1), ocsp_multi(YY), (255) } CertificateStatusType;

NEW:

    enum { ocsp(1), ocsp_multi(YY), scvp (AA), (255)
    } CertificateStatusType;

    struct {
      ResponderID responder_id_list<0..2^16-1>;
      Extensions request_extensions;
    } SCVPStatusRequest;

Going with the though that we'd send the same type of information in, 
but this might be a bit simple minded.

Obviously a bunch of text is needed for this too, but I figure I'd hold 
up here while we decide if this is the right approach.

12) s2.2/6: r/CCITT/ITU
For these I guess maybe move the X.690 reference earlier to the first 
occurrence or just put it everywhere:
    s2.2: r/DER encoding/DER [ITU.X.690.2002] encoding
    s2.2: r/are DER-encoded ASN.1 types/
            are DER-encoded [ITU.X.690.2002] ASN.1 types

13) s4.1: I'd add the following motherhood and apple pie:

   The security considerations of [RFC2560] to OCSP requests
   and responses.

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 May 2012 12:44:35 -0400

After thinking about this some, I should have been clearer about the 
SCVP changes.  They're suggestions not direction.  That is, if the WG 
consensus is to not include SCVP then I'll live with being in the rough.

spt

On 5/26/12 4:08 PM, Sean Turner wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Rob Stradling <[email-masked]>
Date: Thu, 31 May 2012 12:13:13 +0100

Yngve,

IIRC, when Opera does an online revocation check, it currently checks 
CRLs for intermediate CA certificates and OCSP for end-entity 
certificates.  This makes sense because:
   - CRLs covering intermediate CA certificates tend to be roughly the 
same size (sometimes smaller!) as the equivalent OCSP Responses (since 
it's quite rare for intermediate CA certificates to be revoked).
   - Possessing a current CRL means you won't have to do an online 
revocation check if you encounter another certificate issued by the same 
issuer.

How would you feel about updating the multi-stapling I-D so that it 
permits CRLs to be stapled (with a note to implementers that they should 
only staple CRLs that are deemed to be "small enough")?

Simply adding something like "case crl_multi: CRLList;" to your 
definition of CertificateStatus.response would be problematic, because 
it would require the server to staple a (potentially huge!) CRL for the 
end-entity certificate too.  So...

How about changing the scope of the multi-stapling I-D so that it *only* 
covers the intermediate CA certificate(s) in the chain?

With this approach, an end-entity OCSP Response could be stapled using 
the RFC6066 TLS extension, and the intermediate CRL(s) could be stapled 
using the new multi-stapling TLS extension.

(End-entity certificate stapling is already defined in RFC6066 and this 
existing TLS extension is already supported by many clients and servers. 
  So why not make the multi-stapling TLS extension complement it, rather 
than replace it?)

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