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

[Sean Turner <[e-mail]>]

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