[TLS] DISCUSS on Client Certificate URLs Section of 4366-bis

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Tue, 17 August 2010 17:42 UTC

Return-Path: <jsalowey@cisco.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E5D3A6B2B for <tls@core3.amsl.com>; Tue, 17 Aug 2010 10:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.076
X-Spam-Level:
X-Spam-Status: No, score=-110.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHVYMXeqyOBx for <tls@core3.amsl.com>; Tue, 17 Aug 2010 10:42:06 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 5B11A3A6B14 for <tls@ietf.org>; Tue, 17 Aug 2010 10:41:33 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgUFAE9makyrR7H+/2dsb2JhbACTJ40XcaVJnAmFNwSEMYgf
X-IronPort-AV: E=Sophos;i="4.55,384,1278288000"; d="scan'208";a="241506129"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2010 17:41:24 +0000
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7HHfOE3027770 for <tls@ietf.org>; Tue, 17 Aug 2010 17:41:24 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:41:25 -0700
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 17 Aug 2010 10:41:21 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50B3B5F88@xmb-sjc-225.amer.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: DISCUSS on Client Certificate URLs Section of 4366-bis
Thread-Index: Acs+M2fPgHxKiw1UQuqKhSewmPf0lA==
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: tls@ietf.org
X-OriginalArrivalTime: 17 Aug 2010 17:41:25.0026 (UTC) FILETIME=[69D8C820:01CB3E33]
Subject: [TLS] DISCUSS on Client Certificate URLs Section of 4366-bis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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, 17 Aug 2010 17:42:07 -0000

Alexey logged some DISCUSS comments on section 5 of
draft-ietf-tls-rfc4366-bis-10 during IESG review.  Below are the
comments and the proposed resolutions.  Please review and send comments
to the list. 

Thanks,

Joe 

1) Comment 1

"  The TLS server is not required to follow HTTP redirects when
   retrieving the certificates or certificate chain.

This is not strong enough for interoperability. Either redirects MUST be
followed, or they MUST NOT be followed. Alternatively there need to be
some
explanation of why SHOULD (or even MAY) is appropriate here.

   The URLs used in
   this extension SHOULD therefore be chosen not to depend on such
   redirects."

It seems that since we recommend not depending upon redirects so I
propose:

"The TLS server MUST NOT follow HTTP redirects when retrieving the
certificates or certificate chain. The URLs used in this extension MUST
NOT be chosen to depend on such redirects."

If we want to leave the possibility for redirects then we need to text
to describe when redirects are allowed.  

2) "If a server encounters an unreasonable delay in obtaining

This is not very specific. Can a minimal value be recommended here?

   certificates in a given CertificateURL, it SHOULD time out and signal
   a certificate_unobtainable(111) error alert.

What are possible alternatives to the SHOULD?

   This alert MAY be fatal;
   for example, if client authentication is required by the server for
   the handshake to continue. "

I propose the following text to resolve this:

"If a server is unable to obtain certificates in a given CertificateURL,
it MUST send a fatal unrecognized_name(112) alert if it requires the
certificates to complete the handshake.  If the server does not require
the certificates then the server continues the handshake.  The server
MAY send a warning level alert in this case.  Clients receiving such an
alert SHOULD log the alert and continue with the handshake if possible."