Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey

Joe Salowey <jsalowey@cisco.com> Wed, 18 April 2012 20:42 UTC

Return-Path: <jsalowey@cisco.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 E59F611E8097 for <tls@ietfa.amsl.com>; Wed, 18 Apr 2012 13:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 aHO7f-cX+27d for <tls@ietfa.amsl.com>; Wed, 18 Apr 2012 13:42:10 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE021F83EF for <tls@ietf.org>; Wed, 18 Apr 2012 13:42:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1457; q=dns/txt; s=iport; t=1334781730; x=1335991330; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=tGyqBhVdNJ62ZRhnPiV2UzAXSQdlaXa1/xPSMO4kCPI=; b=CsUY3JDnLwOFBaUv+K5/FprFSqYYx43YJOgdDKYNEkkjiDJDTATQy7/g fqyw7lf4kW8VqSoOBDwhrneujNMbCUR+NLG7+IyH7F75sxJOJ1wb8i9zZ yKe+pdpe+p5Lz0Rh+kO4lwzif7FrdFhYeT3oMK+cKcudBvl/EnpZsXfU7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AicGAEQmj0+rRDoI/2dsb2JhbAA6CoMcriWBB4IJAQEBAwEBAQEPASc0CwULCxguJzAGEyKHaAQMmnGgIwSKYIRyYwSIXI0ThXOIXoFpgwc
X-IronPort-AV: E=Sophos;i="4.75,443,1330905600"; d="scan'208";a="41154052"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 18 Apr 2012 20:42:10 +0000
Received: from [10.33.248.190] ([10.33.248.190]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3IKg8P6002941; Wed, 18 Apr 2012 20:42:09 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Joe Salowey <jsalowey@cisco.com>
In-Reply-To: <alpine.LFD.2.02.1204111401400.24167@bofh.nohats.ca>
Date: Wed, 18 Apr 2012 13:42:07 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B82906A2-4640-4DEB-B3B6-AEAAC302EB63@cisco.com>
References: <173124B6-9480-443E-9FA6-98BBB1A01F5F@vpnc.org> <alpine.LFD.2.02.1204051126330.4059@bofh.nohats.ca> <F53123FA-2A9C-434D-92CF-0B938B072984@vpnc.org> <alpine.LFD.2.02.1204100955050.5054@bofh.nohats.ca> <BB11250E-D827-490A-9C9D-C83028844EF6@vpnc.org> <alpine.LFD.2.02.1204101202270.11272@bofh.nohats.ca> <01c901cd1801$9cff3fa0$d6fdbee0$@augustcellars.com> <alpine.LFD.2.02.1204111401400.24167@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.1084)
Cc: Jim Schaad <ietf@augustcellars.com>, tls@ietf.org
Subject: Re: [TLS] Client certificate authentication and draft-ietf-tls-oob-pubkey
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: Wed, 18 Apr 2012 20:42:15 -0000

Hi Paul,

Can you submit an updated draft with the clarification that support for client auth is only through SPKI lookups?  Then we can take the draft to WGLC.  

Thanks,

Joe  
On Apr 11, 2012, at 11:10 AM, Paul Wouters wrote:

> On Wed, 11 Apr 2012, Jim Schaad wrote:
> 
>>> Oops. I checked draft-wouters-tls-oob-pubkey-00 and it was already
>>> removed there after discussion with EKR in Quebec City.
>> 
>> If this is really what you want to do, then I would suggest that the
>> document be expanded so that there exists the possibility to include an
>> identifier and/or a public key in the certificate form defined by the oob
>> document.
> 
> Personall, I strongly prefer not adding more fields to the bare key certificate
> type, as those people who want to cover client authentication can use
> full PKIX certs already, and TLS client authentication in the wild seems
> to be extremely rare. The only two cases I knew are CAcert and Fedora
> (and for the latter it does not even add security, as I need to identify
> with another factor anyway (yubikey))
> 
> Is there an actual use case where bare keys would be preferable over
> full PKIX, that also include client auth not based on burned in keys
> covered by server side SPKI lookups?
> 
> Paul
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls