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

[Sean Turner <[e-mail]>]

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:
> 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
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>