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

Sean Turner <turners@ieca.com> Tue, 29 May 2012 16:44 UTC

Return-Path: <turners@ieca.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E63011E80B6 for <tls@ietfa.amsl.com>; Tue, 29 May 2012 09:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.131
X-Spam-Level:
X-Spam-Status: No, score=-102.131 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iQ53dnxnSzlC for <tls@ietfa.amsl.com>; Tue, 29 May 2012 09:44:37 -0700 (PDT)
Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.159.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6555A11E80B5 for <tls@ietf.org>; Tue, 29 May 2012 09:44:37 -0700 (PDT)
Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 0B4E17456377B; Tue, 29 May 2012 11:44:37 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 000747456374A for <tls@ietf.org>; Tue, 29 May 2012 11:44:36 -0500 (CDT)
Received: from [71.191.15.83] (port=41551 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <turners@ieca.com>) id 1SZPXA-0004fT-Bx for tls@ietf.org; Tue, 29 May 2012 11:44:36 -0500
Message-ID: <4FC4FCF3.9010605@ieca.com>
Date: Tue, 29 May 2012 12:44:35 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: tls@ietf.org
References: <20120509153513.11861.32080.idtracker@ietfa.amsl.com> <4FC13826.9010900@ieca.com>
In-Reply-To: <4FC13826.9010900@ieca.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [71.191.15.83]:41551
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 2
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Subject: Re: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 May 2012 16:44:38 -0000

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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>