From Jeff.Hodges@KingsMountain.com Fri Oct 1 11:01:13 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D61ED3A6D0D for ; Fri, 1 Oct 2010 11:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.14 X-Spam-Level: X-Spam-Status: No, score=-102.14 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 iBuhru4KJQN9 for ; Fri, 1 Oct 2010 11:01:12 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id B94783A6C38 for ; Fri, 1 Oct 2010 11:01:12 -0700 (PDT) Received: (qmail 400 invoked by uid 0); 1 Oct 2010 18:02:01 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 1 Oct 2010 18:02:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=gduV/sfFRCeeEttwW7uPAvJTfV8bJtT7VL5jzmei398b8tMn/Rd+5rtoQBEM15LWEeBZqosUdCjGZK/Q0yF9kp44idEmF/R8XAfecqIBqjzlvathMulr0dJizwoW/u65; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P1jvk-0003if-Rh for certid@ietf.org; Fri, 01 Oct 2010 12:02:00 -0600 Message-ID: <4CA62216.3070508@KingsMountain.com> Date: Fri, 01 Oct 2010 11:01:58 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Oct 2010 18:01:13 -0000 Jim Schaad replied: > Martin Rex replied: >> Jim Schaad wrote: >> > >> > If there is only one possible certification path then there is no >> > difference between caching just the EE certificate and caching the >> > entire chain. However in the event that multiple certificate paths >> > are possible there may be a difference in behavior. >> >> Nope, not for what is specified in server-id-check. >> >> At most, the client would have to memorize along with the server cert >> whether regular certificate path validation worked for this cached cert. >> Any changes to the path (above the server cert) will either make the cert >> path validation fail or be security-irrelevant--entirely without caching >> and comparing chain certs above the cached/pinned server cert. > > There is no need to remember that path validation has passed or failed - by > definition it has passed or you would never even get here. The document > does not "permit" the case of using a certificate if path validation has > failed. Agreed. Perhaps we could make this more clear in sections "1.3. Applicability" and "1.4.2. Out of Scope". =JeffH From Jeff.Hodges@KingsMountain.com Sun Oct 3 17:44:18 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8CDB3A6B8E for ; Sun, 3 Oct 2010 17:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.559 X-Spam-Level: X-Spam-Status: No, score=-100.559 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_28=0.6, 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 qpNk8j93TFC7 for ; Sun, 3 Oct 2010 17:44:17 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id DBC1C3A6E7E for ; Sun, 3 Oct 2010 17:44:14 -0700 (PDT) Received: (qmail 8302 invoked by uid 0); 4 Oct 2010 00:45:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 4 Oct 2010 00:45:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=b+yCbX60JmhYryTw0qXa6AYWC8XRjHP5t24lRTeh8KcOCoBv9uMPgK2o0yStI7ExjPH3++L2wNogjGbIPZQFrrNgQ8rB7qf12/0F2RQRsHWuUUIUezkl8XAJXH9dKTBY; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P2ZAx-0001rs-2r for certid@ietf.org; Sun, 03 Oct 2010 18:45:07 -0600 Message-ID: <4CA9238F.1070709@KingsMountain.com> Date: Sun, 03 Oct 2010 17:45:03 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [certid] fyi: assessment of present compatibility of CN-ID, DNS-ID (SAN:dNSName) by Paul Tiemann (digicert) (was: Need to define "most specific RDN") X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 00:44:18 -0000 [ forwarding with permission of the author (I didn't write the below) in order that we have this info publicly available in the archives ] Subject: Fwd: [certid] Need to define "most specific RDN" From: Paul Tiemann Date: Fri, 16 Jul 2010 11:56:11 -0600 (10:56 PDT) To: Jeff Hodges , Kaspar Brand (Here's what I think I... oops, I sent it only to Kaspar -- I'll fix that and send it to certid) ---------- Forwarded message ---------- From: Paul Tiemann Date: Fri, Jul 16, 2010 at 9:07 AM Subject: Re: [certid] Need to define "most specific RDN" To: Kaspar Brand On Wed, Jul 14, 2010 at 11:07 PM, Kaspar Brand wrote: > On 14.07.2010 17:47, Nelson B Bolyard wrote: > > I'm doubtful if adding a MUST NOT for CN-IDs (vs. a SHOULD NOT) would > have a considerable impact on future CA practices. Most of them probably > don't want to risk compatibility issues with legacy implementations > (which don't recognize the subjectAltName extension). > > You're right. CAs are most likely to want maximum compatibility, and there are still enough devices and clients in circulation that only do Common Name matching. See this page for a few devices that are known not to handle SANs: http://www.digicert.com/subject-alternative-name-compatibility.htm According to my research, and DigiCert's experience issuing certificates with and without SAN extensions, here is a simple hierarchy of best-to-worst compatibility for server certificates with only one FQDN (ex: www.digicert.com) to match: 1) For best compatibility, issue the certificate with CN=www.digicert.com, do not include SAN extension at all. Everything currently supports non-wildcard CN matching. Some platforms do not support wildcards (Windows Mobile 5) 2) Only slightly less compatible: issue with CN=www.digicert.com, and non-critical SAN=(dnsName=www.digicert.com) There was some talk about always including the SAN extension a few months ago on the CA/Browser forum. To try to be a good CA citizen, I went ahead and made a change so that our certificates would do this (add a 1-element SAN even if there is only one server ID to be covered by the certificate) I had to roll back, because within two days (it might have been the very next day) we got a call from a customer whose server was not accepting the certificate because the SAN extension was present. I remember it was some kind of issue with a blackberry server. I asked for details about their platform and version, but I don't believe I got them and I forgot to go back and ask again. For now, we're back to using method #1. That said, there's a good chance I could switch back to this and never hear of the problem again. At least half of all our certificates include the SAN extension and we've almost never had issues with products choking on the mere presence of the extension (that really is very rare) 3) Still less compatible: issue with CN=www.digicert.com, and CRITICAL SAN=(dnsName=www.digicert.com) When the SAN extension is marked critical, some Java based clients or servers will choke. Perhaps it's all Java versions older than 2007, but sadly that describes a fair amount of enterprise customers who run various legacy applications on very old JVM versions. 4) Least compatible: issue with CN=DigiCert, Inc or no CN at all, and non-critical SAN=(dnsName=www.digicert.com) I agree with Nelson's recent post, however, that I would prefer it if the CN were restricted to just one spot. There are too many browsers already behaving differently when there are more than one CN in a subject. Dan Kaminsky found Firefox, IE, and openssl behave differently when they see more than one CN in a subject. Almost all certificates I'm aware of have only one CN in them -- and making it even more rare would be a step forward in my opinion. My opinion on steps for improvement from where we are now: 1) Clarify CN usage by strongly recommending only 1 CN in a subject. 2) Encourage ubiquitous usage of the SAN extension, so that almost all CA issued certificates include the SAN extension, only deviating from that for reasons of compatibility with legacy servers or clients which choke on the SAN. 3) Make strong recommendations to stop using CN-IDs in subject 4) Stop using server-IDs in common names experimentally On the topic of name constraints: What if there are ways to push Name Constraints forward without necessarily having to wait for all legacy clients to die and all the niche clients to become compatible? Here's one idea (admittedly not past v0.1 in my head) 1) Have the major browser vendors add a small mechanism to detect certificates with Name Constraint violations, and give them a central, automated way to "report" a certificate found with violated name constraints which might pose a risk for all the non-compliant browsers and clients. With something like that in place, the major browsers will be able to handle name constraints correctly, and the constraints policing feature would help to erase the incentive that the operator of a constrained CA certificate would have for violating the constraints to trick legacy devices. 2) NetCraft could possibly help with Name Constraints monitoring, at least for the public internet. 3) Eventually at some date in the distant future, all the legacy devices will be dead, and all clients will be compatible, and the programs in #1 and #2 could be dismantled. Paul Tiemann (CTO, DigiCert) From matt@mattmccutchen.net Sun Oct 3 19:24:41 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 747113A6E2E for ; Sun, 3 Oct 2010 19:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] 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 QAXNFeTSO6Rh for ; Sun, 3 Oct 2010 19:24:40 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 766D33A6CD4 for ; Sun, 3 Oct 2010 19:24:40 -0700 (PDT) Received: from homiemail-a5.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTP id ADA7070406A; Sun, 3 Oct 2010 19:25:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=G3gCCgoDGjdZNHNTJOUsWBvHA/+A+XIhR9cZkggXZ2T CSHCj7knYwHR3PQ+e3gSfwt1bkJ4x/gVcG9h32JnNqqDjlhjSSHHDC65O1Bk6Qpe pmdmH1fykfyz0ujB8+VY4Mln7BU4g+JCpLNfbzGvQZfyZC7RueAqowev5eJ1eDoI = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=xTFxApfYNAhP6ZTm3gtkjU1AU1A=; b=FjBqZlTlMJ 9MCSoBLdufffuPXKU/6tjHtziH4ckBPylgxYxLAmTjWfzFcK9PYUG9R/xvikum4k mPeyYJd3bh4RAmKimjBmyfVnvjxUiNrB5P8QeDAcVM5OemnJHLHajjxrcI6qT0e1 YlB0BdBwKAMJfY7FPwBTM0Ws093RzzEwY= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a5.g.dreamhost.com (Postfix) with ESMTPA id 52E18704063; Sun, 3 Oct 2010 19:25:34 -0700 (PDT) From: Matt McCutchen To: =JeffH In-Reply-To: <4CA9238F.1070709@KingsMountain.com> References: <4CA9238F.1070709@KingsMountain.com> Content-Type: text/plain; charset="UTF-8" Date: Sun, 03 Oct 2010 22:25:33 -0400 Message-ID: <1286159133.14732.74.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] fyi: assessment of present compatibility of CN-ID, DNS-ID (SAN:dNSName) by Paul Tiemann (digicert) (was: Need to define "most specific RDN") X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 02:24:41 -0000 On Sun, 2010-10-03 at 17:45 -0700, =JeffH wrote: > [ forwarding with permission of the author (I didn't write the below) in order > that we have this info publicly available in the archives ] [...] > You're right. CAs are most likely to want maximum compatibility, and there > are still enough devices and clients in circulation that only do Common Name > matching. [...] Essentially the same message is already in the archive: http://www.ietf.org/mail-archive/web/certid/current/msg00256.html But thanks for sending it again: I realized I wanted to reply to the part about name constraints. -- Matt From matt@mattmccutchen.net Sun Oct 3 19:49:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 428B33A6F15 for ; Sun, 3 Oct 2010 19:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] 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 Gs6SIMC8ICr0 for ; Sun, 3 Oct 2010 19:49:19 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 0BA7B3A6F12 for ; Sun, 3 Oct 2010 19:49:19 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 710108C06C; Sun, 3 Oct 2010 19:50:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=OxjyVMmvUWSbmPmzaTwuQUzSVAyhdwF0K3yTlc8EkTH hqKxCJ5spJU2NvGEcttkekwKZqn99+go6D0PcdogZxUstf5aRpnZxeJmd0jEBlXQ 970puNXWrts2mLeDbk7DUz7FlXgbMsStcRQKBe4LrHJ8CbOsKgxLB+gCOPe39Bqs = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=UkhUtnThSHIk1H+eKWBka03iat4=; b=nwzcZ6WZmw kdKXpjE/S+ByffKnh+uzZCazCNmmq2CWeJd2vYMhC/hWOYp5Ls5OODbkBskHVdT6 moM9Ec8+8VBTEoWK36HQQ28Dv7PoIikWJClWkROuuv8ASS1ggijp9s2XCtS8goSI uE6IdRFwBldG01VhSKiUIWd4W4AqW6FfI= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPA id 2982D8C06A; Sun, 3 Oct 2010 19:50:13 -0700 (PDT) From: Matt McCutchen To: Paul Tiemann In-Reply-To: References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3DDC18.4020808@bolyard.me> <4C3E979B.4050401@velox.ch> Content-Type: text/plain; charset="UTF-8" Date: Sun, 03 Oct 2010 22:50:11 -0400 Message-ID: <1286160611.14732.125.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Name constraints and legacy clients X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 02:49:20 -0000 On Fri, 2010-07-16 at 12:02 -0600, Paul Tiemann wrote: > On the topic of name constraints: What if there are ways to push Name > Constraints forward without necessarily having to wait for all legacy > clients to die and all the niche clients to become compatible? Here's > one idea (admittedly not past v0.1 in my head) > > 1) Have the major browser vendors add a small mechanism to detect > certificates with Name Constraint violations, and give them a central, > automated way to "report" a certificate found with violated name > constraints which might pose a risk for all the non-compliant browsers > and clients. With something like that in place, the major browsers > will be able to handle name constraints correctly, and the constraints > policing feature would help to erase the incentive that the operator > of a constrained CA certificate would have for violating the > constraints to trick legacy devices. > 2) NetCraft could possibly help with Name Constraints monitoring, at > least for the public internet. And at this point it becomes safe to give someone we don't fully trust a name-constrained intermediate certificate? I'm skeptical. An attacker may be able to target some subset of legacy clients with a false certificate (by source IP address or ClientHello content) without ever sending the certificate to a violation-reporting client and thereby evade detection. Another approach is to have name-constrained intermediate certificates include a critical extension that means "name constraints must be applied to the CN-ID". EE certificates under such an intermediate certificate will only be accepted by clients that properly enforce the name constraints. An organization could use a name-constrained intermediate certificate for servers that don't need to support legacy clients and get a certificate directly from a public CA for servers that do. I previously proposed this here: -- Matt From matt@mattmccutchen.net Sun Oct 3 19:50:08 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 881B83A6F17 for ; Sun, 3 Oct 2010 19:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] 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 I8y7mKX1aKdV for ; Sun, 3 Oct 2010 19:50:06 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by core3.amsl.com (Postfix) with ESMTP id 4448C3A6F12 for ; Sun, 3 Oct 2010 19:50:06 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 80075578071; Sun, 3 Oct 2010 19:51:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=M4QjnFYHqbajTbWTNJJqR5dyHjPuIY1lfUpqq53a7tQ TknV2D9JNBsX6P5SKjFu7gVS2GORqgz1xiRNHh+poM4zGmX0afpOrcVpgg+T7aF8 K8gE8QE/fRYMWPXyxqkiQ1OPtqu+son7/ZpyML9eqPexKMUmeldljB2gsPhh0YvU = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=ydSpgX3cxWk7uj86rGQop4D+9gw=; b=ROZCcF4nJQ 3OegMZ7LmdG8M46vEd92zrxd5N2ywMrrR4xsqjbIHRwwkbvwkWx9feuy7AsDqxXR TQNNAgT34wk524Wrmp2Cwp+PSBHH76E6XsSWL98TpBjZArLfVsn/slnNt7Hmd4+P 4DJWnwUGaMUtoCndbloH3HXOHsvonIwzo= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id EFC2F57806C; Sun, 3 Oct 2010 19:50:59 -0700 (PDT) From: Matt McCutchen To: Paul Tiemann In-Reply-To: <1286160611.14732.125.camel@mattlaptop2.local> References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3DDC18.4020808@bolyard.me> <4C3E979B.4050401@velox.ch> <1286160611.14732.125.camel@mattlaptop2.local> Content-Type: text/plain; charset="UTF-8" Date: Sun, 03 Oct 2010 22:50:59 -0400 Message-ID: <1286160659.14732.126.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] Name constraints and legacy clients X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 02:50:08 -0000 On Sun, 2010-10-03 at 22:50 -0400, Matt McCutchen wrote: > Another approach is to have name-constrained intermediate certificates > include a critical extension that means "name constraints must be > applied to the CN-ID". EE certificates under such an intermediate > certificate will only be accepted by clients that properly enforce the > name constraints. An organization could use a name-constrained > intermediate certificate for servers that don't need to support legacy > clients and get a certificate directly from a public CA for servers that > do. I previously proposed this here: Sorry. https://bugzilla.mozilla.org/show_bug.cgi?id=554442 -- Matt From paul.tiemann.usenet@gmail.com Mon Oct 4 06:47:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B9CF3A6F92 for ; Mon, 4 Oct 2010 06:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 X1y6JSEu4PP0 for ; Mon, 4 Oct 2010 06:47:37 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 52D953A6C91 for ; Mon, 4 Oct 2010 06:47:37 -0700 (PDT) Received: by pwi3 with SMTP id 3so1758256pwi.31 for ; Mon, 04 Oct 2010 06:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=c8QTG5N2YTGJWK82wcD3NM3ds6rGgOik86lDQYOM12Q=; b=hZsf90w15hebnPLBtssm2NG9Ni3RMv1y0wpcxrfeUfHM0Nn8LgyDNFgLpgrOFp5BmR B/r+Flqt5Z2yeSsUTmPzhURJQ6XK3icNWo5ShJWyM/XGdCNVSrpvJLnEJV3xkXAe1Z8q D/bbryg6nkubXwjUig/HDlqCkBcUopZ5PLk1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=D+Ml2f3KRVl66KhA+xbjiuNW3xCaJDiyLlpzsIvjWFAXrrE/0t2M/ReIzdwjlqh8wc VvyiiDbhw/0MBp3bBhqlezQoEMJjPeqNadb8OT2XvN9N6I6rCsS7h+0KsrO2/eGZwcxf kSV46C/RDHd33KlCFP3L342hGZnmfEPnWJjGk= Received: by 10.142.135.17 with SMTP id i17mr8595266wfd.278.1286199950646; Mon, 04 Oct 2010 06:45:50 -0700 (PDT) Received: from [10.0.10.100] (c-174-52-143-18.hsd1.ut.comcast.net [174.52.143.18]) by mx.google.com with ESMTPS id x8sm4819880wff.11.2010.10.04.06.45.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 04 Oct 2010 06:45:50 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Paul Tiemann In-Reply-To: <1286160611.14732.125.camel@mattlaptop2.local> Date: Mon, 4 Oct 2010 07:45:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201006301746.o5UHkIsE019133@fs4113.wdf.sap.corp> <4C2B843A.5010206@stpeter.im> <4C305B93.9090001@velox.ch> <201007061435.29786.ludwig.nussel@suse.de> <4C335CE5.1090608@edelweb.fr> <4C3421B3.3070404@velox.ch> <4C3B4F6E.80903@stpeter.im> <4C3DDC18.4020808@bolyard.me> <4C3E979B.4050401@velox.ch> <1286160611.14732.125.camel@mattlaptop2.local> To: Matt McCutchen X-Mailer: Apple Mail (2.1081) Cc: certid@ietf.org Subject: Re: [certid] Name constraints and legacy clients X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 13:47:39 -0000 On Oct 3, 2010, at 8:50 PM, Matt McCutchen wrote: > On Fri, 2010-07-16 at 12:02 -0600, Paul Tiemann wrote: >> On the topic of name constraints: What if there are ways to push Name >> Constraints forward without necessarily having to wait for all legacy >> clients to die and all the niche clients to become compatible? = Here's >> one idea (admittedly not past v0.1 in my head) >>=20 >> 1) Have the major browser vendors add a small mechanism to detect >> certificates with Name Constraint violations, and give them a = central, >> automated way to "report" a certificate found with violated name >> constraints which might pose a risk for all the non-compliant = browsers >> and clients. With something like that in place, the major browsers >> will be able to handle name constraints correctly, and the = constraints >> policing feature would help to erase the incentive that the operator >> of a constrained CA certificate would have for violating the >> constraints to trick legacy devices. =20 >> 2) NetCraft could possibly help with Name Constraints monitoring, at >> least for the public internet. >=20 > And at this point it becomes safe to give someone we don't fully trust = a > name-constrained intermediate certificate? I'm skeptical. An = attacker > may be able to target some subset of legacy clients with a false > certificate (by source IP address or ClientHello content) without ever > sending the certificate to a violation-reporting client and thereby > evade detection. Here's my cue to admit that I didn't think too long about that kind of = risk before sending it out. =20 Just to be clear about my intent: DigiCert hasn't ever issued an = intermediate cert to an external entity, and we've never yet had any = interest in issuing name-constrained intermediate certs either. "Trust = is good, but control is better." This was just part of a thread where = Name Constraints were being discussed, and I thought I'd go ahead and = toss out some ideas about Name Constraints while I was at it.=20 > Another approach is to have name-constrained intermediate certificates > include a critical extension that means "name constraints must be > applied to the CN-ID". EE certificates under such an intermediate > certificate will only be accepted by clients that properly enforce the > name constraints. An organization could use a name-constrained > intermediate certificate for servers that don't need to support legacy > clients and get a certificate directly from a public CA for servers = that > do. I previously proposed this here: >=20 > https://bugzilla.mozilla.org/show_bug.cgi?id=3D554442 Hmm, my guess is that there won't be enough demand for an intermediate = cert that causes all legacy browsers to choke. (Not enough demand for a = CA to want to build it is what I'm guessing...) Paul Tiemann CTO, DigiCert= From mrex@sap.com Mon Oct 4 12:28:10 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7210F3A6E40 for ; Mon, 4 Oct 2010 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.845 X-Spam-Level: X-Spam-Status: No, score=-9.845 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 LFFJSMn6IGhx for ; Mon, 4 Oct 2010 12:28:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C83CD3A6C1C for ; Mon, 4 Oct 2010 12:28:08 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o94JT01g015298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 21:29:00 +0200 (MEST) From: Martin Rex Message-Id: <201010041928.o94JSwa7017455@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Mon, 4 Oct 2010 21:28:58 +0200 (MEST) In-Reply-To: <00a601cb610a$dc119c60$9434d520$@augustcellars.com> from "Jim Schaad" at Sep 30, 10 06:49:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 19:28:10 -0000 I wrote about two issues: (1) lack of rationale why the cert chain should be cached rather than only the server certificate (2) support for server certs that do not succeed certificate path validation to one of the (pre-)configured trust anchors You did not provide any arguments for (1) and inappropriately dismiss (2) for the scope of the current document. I think that (1) is seriously underspecified. With the existing matching procedure, caching the entire cert chain does NOT make any sense at all (and does not provide security benefit). Jim Schaad wrote: > > There is no need to remember that path validation has passed or failed - by > definition it has passed or you would never even get here. The document > does not "permit" the case of using a certificate if path validation has > failed. The previous document (rfc-2818) certainly did allow arbitrary certs and left the notion when a server cert is acceptable completely out-of-scope (it does NOT say PKIX certificate path validation anywhere): http://tools.ietf.org/html/rfc2818#section-3.1 If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) This document here sensibly explains why you may want to allow server certs that do not chain to pre-trusted roots: http://www.w3.org/TR/wsc-ui/#selfsignedcerts > > This document makes absolutely no statements about ever doing anything > positive with untrusted certificates. If the certificate is untrusted - > i.e. fails path validation -- then all bets are off and the document does > not apply in any way. After all if you don't trust the certificate why > would you believe anything that the certificate says about the identity that > is associated with the certificate. This is a complete non-issue for the > document. If this documents engages at all into discussion when a server cert is valid/acceptable for performing server-id-check, then it should _not_ limit the scope to trust anchors preconfigured by software distributors. The current wording about NAGGING end users when the server cert does not map to a pre-configured trust anchor and offering the "pinning" of server-certs to advanced users only is inappropriate for an IETF specification. The W3C spec is much more reasonable in that respect. > > > > > Pinning server certs protects you from attackers that manage to get a cert > > issued from any of the CAs operating under any of your (pre-)trusted > > roots. Performing certificate path validation even for "pinned" certs > > protects you from missing revocations. > > Remember this only discussing the case of being unable to complete the logic > dealing with comparing the reference and the presented names. This is not > dealing any cases where path validation either fails or is not performed. > Thus the idea of pinning a certificate that passes (or does not pass > validation) is not part of the concepts we are discussing here. The document discusses the situation of a "cached server cert", without going into details about why the certificate was cached, what meta-information was cached along with it (giving more context to the decision to cache/pin the server certificate), and it talks about how to perform server-id-check when a cached/pinned certificate exists. The current description is artificially limited to be applicable to the pre-configured commercial CA trust anchors, and doesn't even mention that it is crippled like this, and that there be other more sensible and more secure reasons for caching/pinning certs that require a different "override" strategy or more fine-grained control over server certificate caching/pinning. Pinning of EE server certs (no matter whether self-signed, from untrusted CAs, or from "common TLS PKI") interferes with server cert rollover. Security-wise, pinning the server cert (effectively pinning the servers public key) is certainly the strongest of all because it cuts most of the points-of-failures completely out of the loop. A "pinning" of server certs from CA-hierarchies (trusted AND untrusted) that allows hidden key/cert-rollover might be useful to the public at large -- which does neither care nor understand the technical details. There, the server-cert issuing CA cert would be pinned along with a set of client-applied constraints like the host or DNS domain to which this pinning applies and whether a server-id-check should still be performed on the server cert. Allowing organizations to run their own CAs makes IMHO a lot of sense (and several companies are doing it already). Having to make every CA from some other organization a full-blown trust anchor is just as bad as an unduly requiring for any such organizational CAs to get signed by a pre-configured commercial trust anchor. ISO specified the ASN.1 OIDs so that they can lease "OID arcs" on a subscription basis to organizations for a significant recurring premium so that they can rake in extra revenues. Fortunately, IANA has been giving out OID arcs under SNMP private enterprises for free, and OIDs from that OID space is used heavily for non-SNMP purposes. :) The existing "TLS PKI", which, for the server identity matching keys off the existing DNS space and DNS delegations, represents close to zero value to the IETF community and the public at large. From a technical perspective, both offer comparable security, so I can understand the motivations behind trying to move to DNSSEC-based distribution of trust. Technically, the existing TLS PKI scheme of matching DNS delegations for server endpoint identification in combination with the complete mind-block for past encounters with a peer has always been a primitive "better-than-nothing" approach to security. Limiting acceptable certs to those distributed by the DNS domain admin himself though DNSSEC signed zones would give those DNS admins some of the control back that they're entitled to have (about assignments and use of DNS domain names), something which is very ill-designed in the existing "TLS PKI". -Martin From ietf@augustcellars.com Tue Oct 5 00:09:57 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DAF3A6DF2 for ; Tue, 5 Oct 2010 00:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] 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 h9wFajoMSOyT for ; Tue, 5 Oct 2010 00:09:55 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id E4A273A6CC4 for ; Tue, 5 Oct 2010 00:09:55 -0700 (PDT) Received: from TITUS (pool-96-225-201-121.ptldor.dsl-w.verizon.net [96.225.201.121]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id EA8156EF67; Tue, 5 Oct 2010 00:10:51 -0700 (PDT) From: "Jim Schaad" To: References: <00a601cb610a$dc119c60$9434d520$@augustcellars.com> from "Jim Schaad" at Sep 30, 10 06:49:16 pm <201010041928.o94JSwa7017455@fs4113.wdf.sap.corp> In-Reply-To: <201010041928.o94JSwa7017455@fs4113.wdf.sap.corp> Date: Tue, 5 Oct 2010 00:19:00 -0700 Message-ID: <015d01cb645d$95c4f440$c14edcc0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDY/W4FwyIqkLueZXYHgdRSAu7YZRB78Yg Content-Language: en-us Cc: certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 07:09:57 -0000 > -----Original Message----- > From: Martin Rex [mailto:mrex@sap.com] > Sent: Monday, October 04, 2010 12:29 PM > To: Jim Schaad > Cc: mrex@sap.com; matt@mattmccutchen.net; stpeter@stpeter.im; > certid@ietf.org > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) > > I wrote about two issues: > > (1) lack of rationale why the cert chain should be cached > rather than only the server certificate Ok - I will work through a more explicit example of how I would look at things. I look upon section 4.6.2 (and follows) to be analogous to the user adding an additional SAN to a certificate that states that one or more of the reference identifiers is being bound to a certificate. As an advanced user, I may still wish some correct path validation to occur. Example: Given that I have a certificate for the web site ietf.russ.housely.org and it changes to two different CAs - one operated by Tim Polk (a government employee and thus containing a number of name constraints to avoid being court marshaled and shot) and one operated by Sean Turner (those contractors will work with anybody). However the address of the website that I typed in is ietf.russ.housley.org. The reference and presented names do not match. If the presented name was correctly in the certificate the path to the Tim Polk CA would fail validation. I may decide that I will accept the certificate only if it continues to validate to the Sean Turner CA on the assumption that he might be more on the ball about looking for such desrepances and getting them resolved, however I might look at the certificate in question and decide that the typo was a certificate issuing problem (having called and gotten a SHA-512 hash from Russ) and that I will currently accept the lack of a name match. Here is a circumstance where I have made the decisions of implicitly adding the SAN based on the path used to validate the certificate. Thus if I get a different valid path (because maybe Sean revoked the certificate) I want to be re-informed that the basis of my decision has been altered. NOTE: This is not a trust decision - this is only a decision on the name mapping issue. > > (2) support for server certs that do not succeed certificate > path validation to one of the (pre-)configured trust anchors This is from the abstract of the document in question: "This document specifies best current practices for representing and verifying the identity of application services in such interactions." As you see the document is about how to do name comparisons. If you believe a document on trust , path validation and pinning are needed I would strongly suggest that you write such a draft. jim > > > You did not provide any arguments for (1) and inappropriately dismiss (2) for > the scope of the current document. > > I think that (1) is seriously underspecified. With the existing matching > procedure, caching the entire cert chain does NOT make any sense at all (and > does not provide security benefit). > > > Jim Schaad wrote: > > > > There is no need to remember that path validation has passed or failed > > - by definition it has passed or you would never even get here. The > > document does not "permit" the case of using a certificate if path > > validation has failed. > > The previous document (rfc-2818) certainly did allow arbitrary certs and left > the notion when a server cert is acceptable completely out-of-scope (it does > NOT say PKIX certificate path validation anywhere): > > http://tools.ietf.org/html/rfc2818#section-3.1 > > If the client has external information as to the expected identity of > the server, the hostname check MAY be omitted. (For instance, a > client may be connecting to a machine whose address and hostname are > dynamic but the client knows the certificate that the server will > present.) > > This document here sensibly explains why you may want to allow server certs > that do not chain to pre-trusted roots: > > http://www.w3.org/TR/wsc-ui/#selfsignedcerts > > > > > > This document makes absolutely no statements about ever doing anything > > positive with untrusted certificates. If the certificate is untrusted > > - i.e. fails path validation -- then all bets are off and the document > > does not apply in any way. After all if you don't trust the > > certificate why would you believe anything that the certificate says > > about the identity that is associated with the certificate. This is a > > complete non-issue for the document. > > If this documents engages at all into discussion when a server cert is > valid/acceptable for performing server-id-check, then it should _not_ limit the > scope to trust anchors preconfigured by software distributors. > The current wording about NAGGING end users when the server cert does not > map to a pre-configured trust anchor and offering the "pinning" > of server-certs to advanced users only is inappropriate for an IETF specification. > The W3C spec is much more reasonable in that respect. > > > > > > > > > > Pinning server certs protects you from attackers that manage to get > > > a cert issued from any of the CAs operating under any of your > > > (pre-)trusted roots. Performing certificate path validation even > > > for "pinned" certs protects you from missing revocations. > > > > Remember this only discussing the case of being unable to complete the > > logic dealing with comparing the reference and the presented names. > > This is not dealing any cases where path validation either fails or is not > performed. > > Thus the idea of pinning a certificate that passes (or does not pass > > validation) is not part of the concepts we are discussing here. > > > The document discusses the situation of a "cached server cert", without going > into details about why the certificate was cached, what meta-information was > cached along with it (giving more context to the decision to cache/pin the > server certificate), and it talks about how to perform server-id-check when a > cached/pinned certificate exists. > > The current description is artificially limited to be applicable to the pre- > configured commercial CA trust anchors, and doesn't even mention that it is > crippled like this, and that there be other more sensible and more secure > reasons for caching/pinning certs that require a different "override" strategy or > more fine-grained control over server certificate caching/pinning. > > > > Pinning of EE server certs (no matter whether self-signed, from untrusted CAs, > or from "common TLS PKI") interferes with server cert rollover. Security-wise, > pinning the server cert (effectively pinning the servers public key) is certainly > the strongest of all because it cuts most of the points-of-failures completely out > of the loop. > > A "pinning" of server certs from CA-hierarchies (trusted AND untrusted) that > allows hidden key/cert-rollover might be useful to the public at large -- which > does neither care nor understand the technical details. > There, the server-cert issuing CA cert would be pinned along with a set of > client-applied constraints like the host or DNS domain to which this pinning > applies and whether a server-id-check should still be performed on the server > cert. > > Allowing organizations to run their own CAs makes IMHO a lot of sense (and > several companies are doing it already). Having to make every CA from some > other organization a full-blown trust anchor is just as bad as an unduly > requiring for any such organizational CAs to get signed by a pre-configured > commercial trust anchor. > > > ISO specified the ASN.1 OIDs so that they can lease "OID arcs" on a subscription > basis to organizations for a significant recurring premium so that they can rake > in extra revenues. > Fortunately, IANA has been giving out OID arcs under SNMP private enterprises > for free, and OIDs from that OID space is used heavily for non-SNMP purposes. > :) > > > The existing "TLS PKI", which, for the server identity matching keys off the > existing DNS space and DNS delegations, represents close to zero value to the > IETF community and the public at large. From a technical perspective, both > offer comparable security, so I can understand the motivations behind trying to > move to DNSSEC-based distribution of trust. > > Technically, the existing TLS PKI scheme of matching DNS delegations for > server endpoint identification in combination with the complete mind-block for > past encounters with a peer has always been a primitive "better-than-nothing" > approach to security. > Limiting acceptable certs to those distributed by the DNS domain admin himself > though DNSSEC signed zones would give those DNS admins some of the control > back that they're entitled to have (about assignments and use of DNS domain > names), something which is very ill-designed in the existing "TLS PKI". > > > -Martin From mrex@sap.com Tue Oct 5 10:46:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8411C3A6FD0 for ; Tue, 5 Oct 2010 10:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.862 X-Spam-Level: X-Spam-Status: No, score=-9.862 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 1MqEpUoiVtDx for ; Tue, 5 Oct 2010 10:46:38 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id B47E23A6FEB for ; Tue, 5 Oct 2010 10:46:37 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o95HlAKQ025696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2010 19:47:10 +0200 (MEST) From: Martin Rex Message-Id: <201010051747.o95Hl8iZ002597@fs4113.wdf.sap.corp> To: ietf@augustcellars.com (Jim Schaad) Date: Tue, 5 Oct 2010 19:47:08 +0200 (MEST) In-Reply-To: <015d01cb645d$95c4f440$c14edcc0$@augustcellars.com> from "Jim Schaad" at Oct 5, 10 00:19:00 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 17:46:39 -0000 Jim Schaad wrote: > > Martin Rex wrote: > > > > (2) support for server certs that do not succeed certificate > > path validation to one of the (pre-)configured trust anchors > > This is from the abstract of the document in question: > > "This document specifies best current practices for > representing and verifying the identity of application services in > such interactions." > > As you see the document is about how to do name comparisons. If you believe > a document on trust , path validation and pinning are needed I would > strongly suggest that you write such a draft. Thanks! I was asking for removal of the reference to path validation from that one paragraph: PeterSA wrote: > > then the client MUST verify that > the presented certificate is the same as the cached certificate, > including verification of the entire certification path. So the "including verification of the entire certification path" should be completely removed, and the "cached certificate" ought to be clarified to mean memorized "CERT-ID" reference identifier to make it clearly distinct from anything related to TLS session caching. Jim Schaad wrote: > > Martin Rex wrote: > > > > (1) lack of rationale why the cert chain should be cached > > rather than only the server certificate > > > > I think that (1) is seriously underspecified. With the existing matching > > procedure, caching the entire cert chain does NOT make any sense at all > > (and does not provide security benefit). > > I look upon section 4.6.2 (and follows) to be analogous to the user adding > an additional SAN to a certificate that states that one or more of the > reference identifiers is being bound to a certificate. As an advanced user, > I may still wish some correct path validation to occur. > > Example [...] Given your example, which admittedly I have difficulty understanding, I firmly believe the use of the term "cached server cert (chain)" is throroughly underspecified in server-id-check and should be fixed and all existing references to "certificate path validation" should be removed. The concept of "caching" implies to shortcut or skip operations and rely on previous results of the same operation (e.g. network round-trips, network bandwidth, computational overhead like PK-crypto-operations or other resource-intensive operations such as OCSP-requests or CRL-downloads&checking). The TLS protocol contains a feature called "TLS session caching", and when used, it normally "saves" not only the PK-crypto-operations for the TLS key exchange (which may be a single PK-crypto operation for each peer for RSA ciphersuites), but also the entire certificate path validation (which usually involves several PK-crypto-operations plus OCSP-requests and CRL-downloads with third parties). As specified in all existing TLS protocol specs, last sentence of section 1, the interpretation of peer certificates is entirely up to the calling application on top of TLS. It is also completely up to the application to decide whether to abort a TLS handshake when PKIX certificate path validation can not be performed for the peer certificate due to a lack of trust. server-id-check is an operation that is performed after the TLS handshake has completed, and the peer certificate can be obtained from the TLS stack, independent of whether the TLS session was resumed from the cache (and certificate path validation skipped) or a full TLS handshake was perfomed. "Pinning" of the server certificate means, that server-id-check is substituted with a comparison of the server's end-entity cert, like a "CERT-ID" reference identifier. The "pinned" server cert must be memorized by the application "somewhere", along with the meta-information for which hostname / reference-identifier the pinning applies and whether PKIX cert validation succeeded on this certificate. There is no security problem with allowing CERT-ID matching for certificate chains for which no certificate path validation can be performed due to a lack of trust. This is what this paragraph of rfc-2818 is about: If the client has external information as to the expected identity of the server, the hostname check MAY be omitted. (For instance, a client may be connecting to a machine whose address and hostname are dynamic but the client knows the certificate that the server will present.) A users decision to "pin" a server cert may involve consideration of chain certificates in case that PKIX certificate path validation succeeded. But memorizing anything besides the server cert will *NOT* provide any security benefit for future automated server endpoint identifications and is unnecessary. If the server-id-check document wants to define a CERT-ID reference identifier and use the term "caching", is should use it in a fashion that there is no confusion with the TLS session caching and that the PKIX certificate path validation usually performed by TLS on behalf of the calling app (but only during full TLS handshakes) is independent from application-level server-id-check, independent of whether DNS-ID, URL-ID, SRV-ID, CN-ID or CERT-ID is used. One should be very careful about the use of the term "caching" in server-id-check so that there is no confusion with anything from the TLS session caching. For server-id-check "caching" applies only to the decision to use the server end-entity cert as the reference identifier ("CERT-ID") for a specific target, instead of deriving reference identifiers such as DNS-ID, URL-ID or CN-ID from the target's hostname that was used to establish the communication channel. This decision could be a result of user-interaction or result of a configuration to that effect. Btw. I would be extremely careful about visualizing chain certificates to Joe Average user for a chain that failed certificate path validation because it is quite undefined how many checks were really skipped. You do NOT want to have Joe Average user perform an eyeball comparison on the cert or public key fingerprint on the top-level cert at the end of a cert chain for which certificate path validation failed and let him assume this makes it a successfull path validation. Given how certificate path validation is specified by PKIX (rfc-5280, section 6), working from the trust anchor downwards, no signature checks, no constraints checks and not revocation checks are performed on an untrusted chain. -Martin From stpeter@stpeter.im Wed Oct 6 09:33:54 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB5B3A7131 for ; Wed, 6 Oct 2010 09:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, 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 rPpW-dCADy9X for ; Wed, 6 Oct 2010 09:33:53 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 471393A70FA for ; Wed, 6 Oct 2010 09:33:53 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E6EA340074; Wed, 6 Oct 2010 10:41:02 -0600 (MDT) Message-ID: <4CACA52A.6030905@stpeter.im> Date: Wed, 06 Oct 2010 10:34:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: =JeffH References: <4CA9238F.1070709@KingsMountain.com> In-Reply-To: <4CA9238F.1070709@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] fyi: assessment of present compatibility of CN-ID, DNS-ID (SAN:dNSName) by Paul Tiemann (digicert) (was: Need to define "most specific RDN") X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 16:33:55 -0000 On 10/3/10 6:45 PM, =JeffH wrote: > [ forwarding with permission of the author (I didn't write the below) in > order that we have this info publicly available in the archives ] > > Subject: Fwd: [certid] Need to define "most specific RDN" > From: Paul Tiemann > Date: Fri, 16 Jul 2010 11:56:11 -0600 (10:56 PDT) > To: Jeff Hodges , Kaspar Brand > Jeff, what is your take? Here's what I see... > My opinion on steps for improvement from where we are now: > > 1) Clarify CN usage by strongly recommending only 1 CN in a subject. I think we already do that, because in our working copy Section 3, bullet 6 states: The certificate MAY contain more than one DNS-ID, but SHOULD NOT contain more than one CN-ID. > 2) Encourage ubiquitous usage of the SAN extension, so that almost all CA > issued certificates include the SAN extension, only deviating from that for > reasons of compatibility with legacy servers or clients which choke on the > SAN. Again I think we already do that, because in our working copy Section 3, bullets 1 through 3 state: 1. The certificate SHOULD include a "DNS-ID" (i.e., a subjectAltName entry of type dNSName) if possible as a baseline for interoperability. 2. If the service using the certificate deploys a technology in which a server is discovered by means of DNS SRV records [DNS-SRV] (e.g., this is true of [XMPP]), then the certificate SHOULD include an "SRV-ID" (i.e., a subjectAltName entry of type otherName whose name form is SRVName as specified in [SRVNAME]); furthermore, multiple instances of the "SRV-ID" identifier type are allowed. 3. If the service using the certificate deploys a technology in which a server is typically associated with a URI (e.g., this is true of [SIP]), then the certificate SHOULD include a URI-ID (i.e., a subjectAltName entry of type uniformResourceIdentifier); the scheme SHALL be that of the protocol associated with the service type and the authority component SHALL be the fully- qualified DNS domain name of the service; furthermore, multiple instances of the "URI-ID" identifier type are allowed. > 3) Make strong recommendations to stop using CN-IDs in subject Done via bullet 5 in Section 3 of our working copy: 5. Even though many deployed clients still check for the CN-ID within the certificate subject name, the certificate SHOULD NOT represent the server's fully-qualified DNS domain name in a CN-ID. > 4) Stop using server-IDs in common names experimentally That's an implementation and deployment issue, not a spec issue, although we would hope that folks do some experiments and report on the results. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Oct 6 10:07:03 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA59D3A6F93 for ; Wed, 6 Oct 2010 10:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, 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 MH0J6XAnYZoB for ; Wed, 6 Oct 2010 10:07:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id C42BC3A6FA4 for ; Wed, 6 Oct 2010 10:07:01 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 543AC40074; Wed, 6 Oct 2010 11:14:11 -0600 (MDT) Message-ID: <4CACACEF.6050205@stpeter.im> Date: Wed, 06 Oct 2010 11:07:59 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mrex@sap.com References: <201010051747.o95Hl8iZ002597@fs4113.wdf.sap.corp> In-Reply-To: <201010051747.o95Hl8iZ002597@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 17:07:03 -0000 On 10/5/10 11:47 AM, Martin Rex wrote: > Jim Schaad wrote: >> >> Martin Rex wrote: >>> >>> (2) support for server certs that do not succeed certificate >>> path validation to one of the (pre-)configured trust anchors >> >> This is from the abstract of the document in question: >> >> "This document specifies best current practices for >> representing and verifying the identity of application services in >> such interactions." >> >> As you see the document is about how to do name comparisons. If you believe >> a document on trust , path validation and pinning are needed I would >> strongly suggest that you write such a draft. > > Thanks! I was asking for removal of the reference to path validation from > that one paragraph: > > PeterSA wrote: >> >> then the client MUST verify that >> the presented certificate is the same as the cached certificate, >> including verification of the entire certification path. > > So the "including verification of the entire certification path" > should be completely removed, I'd be curious to see what Jim's feedback is on that point, since he suggested the inclusion of text about the certification path. > and the "cached certificate" > ought to be clarified to mean memorized "CERT-ID" reference identifier > to make it clearly distinct from anything related to TLS session caching. 1. How about changing "cached certificate" to "stored certificate" or "memorized certificate"? I agree that the term "caching" might be confusing to some folks. 2. Are you suggesting that we change "cached certificate" to "stored reference identifier"? That doesn't strike me as a helpful change because it doesn't make clear that the client needs to keep track of more than just the reference identifier, it needs to store an association between the verified reference identifier (im.example.com or whatever) and the certificate that was presented by the server it connected to for that DNS domain name (or, at the very least, a hash of the certificate). > Jim Schaad wrote: >> >> Martin Rex wrote: >>> >>> (1) lack of rationale why the cert chain should be cached >>> rather than only the server certificate >>> >>> I think that (1) is seriously underspecified. With the existing matching >>> procedure, caching the entire cert chain does NOT make any sense at all >>> (and does not provide security benefit). >> >> I look upon section 4.6.2 (and follows) to be analogous to the user adding >> an additional SAN to a certificate that states that one or more of the >> reference identifiers is being bound to a certificate. As an advanced user, >> I may still wish some correct path validation to occur. >> >> Example [...] > > > Given your example, which admittedly I have difficulty understanding, > I firmly believe the use of the term "cached server cert (chain)" > is throroughly underspecified in server-id-check and should be > fixed and all existing references to "certificate path validation" > should be removed. > > The concept of "caching" implies to shortcut or skip operations and > rely on previous results of the same operation (e.g. network round-trips, > network bandwidth, computational overhead like PK-crypto-operations > or other resource-intensive operations such as OCSP-requests or > CRL-downloads&checking). > > The TLS protocol contains a feature called "TLS session caching", > and when used, it normally "saves" not only the PK-crypto-operations > for the TLS key exchange (which may be a single PK-crypto operation > for each peer for RSA ciphersuites), but also the entire certificate path > validation (which usually involves several PK-crypto-operations plus > OCSP-requests and CRL-downloads with third parties). > > As specified in all existing TLS protocol specs, last sentence of > section 1, the interpretation of peer certificates is entirely up > to the calling application on top of TLS. It is also completely > up to the application to decide whether to abort a TLS handshake > when PKIX certificate path validation can not be performed for > the peer certificate due to a lack of trust. > > server-id-check is an operation that is performed after > the TLS handshake has completed, and the peer certificate > can be obtained from the TLS stack, independent of whether > the TLS session was resumed from the cache (and certificate > path validation skipped) or a full TLS handshake was perfomed. > > "Pinning" of the server certificate means, that server-id-check > is substituted with a comparison of the server's end-entity cert, > like a "CERT-ID" reference identifier. The "pinned" server cert > must be memorized by the application "somewhere", along with the > meta-information for which hostname / reference-identifier the > pinning applies and whether PKIX cert validation succeeded > on this certificate. There is no security problem with allowing > CERT-ID matching for certificate chains for which no certificate > path validation can be performed due to a lack of trust. > > This is what this paragraph of rfc-2818 is about: > > If the client has external information as to the expected identity of > the server, the hostname check MAY be omitted. (For instance, a > client may be connecting to a machine whose address and hostname are > dynamic but the client knows the certificate that the server will > present.) > > A users decision to "pin" a server cert may involve consideration > of chain certificates in case that PKIX certificate path validation > succeeded. But memorizing anything besides the server cert will *NOT* > provide any security benefit for future automated server endpoint > identifications and is unnecessary. Aha, I see your point now. Thanks for explaining it in more detail. > If the server-id-check document wants to define a CERT-ID reference > identifier and use the term "caching", is should use it in a fashion > that there is no confusion with the TLS session caching and that > the PKIX certificate path validation usually performed by TLS > on behalf of the calling app (but only during full TLS handshakes) > is independent from application-level server-id-check, independent > of whether DNS-ID, URL-ID, SRV-ID, CN-ID or CERT-ID is used. > > One should be very careful about the use of the term "caching" > in server-id-check so that there is no confusion with anything > from the TLS session caching. Yes, point taken. > For server-id-check "caching" applies > only to the decision to use the server end-entity cert as the > reference identifier ("CERT-ID") for a specific target, In the terms of this I-D, a certificate is not a reference identifier. The reference identifier is still a DNS-ID or whatever, it's just that after pinning the client considers it acceptable to use as a reference identifier a DNS domain name that was presented in the server's certificate during a previous connection attempt and explicitly accepted by a human user (as long as the memorized certificate doesn't change in future connection attempts etc.). > instead > of deriving reference identifiers such as DNS-ID, URL-ID or CN-ID > from the target's hostname that was used to establish the > communication channel. This decision could be a result of > user-interaction or result of a configuration to that effect. Correct. > Btw. I would be extremely careful about visualizing chain certificates > to Joe Average user for a chain that failed certificate path validation > because it is quite undefined how many checks were really skipped. > You do NOT want to have Joe Average user perform an eyeball comparison > on the cert or public key fingerprint on the top-level cert at the > end of a cert chain for which certificate path validation failed > and let him assume this makes it a successfull path validation. Yes, applications need to be extremely careful about presenting anything to Joe Average or Barry's Mother or other unsophisticated individuals. > Given how certificate path validation is specified by PKIX > (rfc-5280, section 6), working from the trust anchor downwards, > no signature checks, no constraints checks and not revocation > checks are performed on an untrusted chain. Noted. Peter -- Peter Saint-Andre https://stpeter.im/ From ietf@augustcellars.com Wed Oct 6 12:53:25 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8AFA3A71A2 for ; Wed, 6 Oct 2010 12:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 67TbDfZ6vs+j for ; Wed, 6 Oct 2010 12:53:24 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by core3.amsl.com (Postfix) with ESMTP id E286E3A7191 for ; Wed, 6 Oct 2010 12:53:23 -0700 (PDT) Received: from TITUS (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id 2593F6A44C; Wed, 6 Oct 2010 12:54:24 -0700 (PDT) From: "Jim Schaad" To: "'Peter Saint-Andre'" , References: <201010051747.o95Hl8iZ002597@fs4113.wdf.sap.corp> <4CACACEF.6050205@stpeter.im> In-Reply-To: <4CACACEF.6050205@stpeter.im> Date: Wed, 6 Oct 2010 12:57:27 -0700 Message-ID: <009c01cb6590$b47e4060$1d7ac120$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI8vQmOUtkwPDSb4xKl2zoNEsmW+QJWti+Vkj7vItA= Content-Language: en-us Cc: certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 19:53:25 -0000 > -----Original Message----- > From: Peter Saint-Andre [mailto:stpeter@stpeter.im] > Sent: Wednesday, October 06, 2010 10:08 AM > To: mrex@sap.com > Cc: Jim Schaad; matt@mattmccutchen.net; certid@ietf.org > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate = handling) >=20 > On 10/5/10 11:47 AM, Martin Rex wrote: > > Jim Schaad wrote: > >> > >> Martin Rex wrote: > >>> > >>> (2) support for server certs that do not succeed certificate > >>> path validation to one of the (pre-)configured trust anchors > >> > >> This is from the abstract of the document in question: > >> > >> "This document specifies best current practices for > >> representing and verifying the identity of application services = in > >> such interactions." > >> > >> As you see the document is about how to do name comparisons. If = you > >> believe a document on trust , path validation and pinning are = needed > >> I would strongly suggest that you write such a draft. > > > > Thanks! I was asking for removal of the reference to path validation > > from that one paragraph: > > > > PeterSA wrote: > >> > >> then the client MUST verify that > >> the presented certificate is the same as the cached certificate, > >> including verification of the entire certification path. > > > > So the "including verification of the entire certification path" > > should be completely removed, >=20 > I'd be curious to see what Jim's feedback is on that point, since he = suggested > the inclusion of text about the certification path. I don't care if you remove the word verification. What I want to say is = that the presented certificate and it's chain back to the trust anchor = is the same as when it was first checked by the advanced user. If the = path has changed then the answer should be re-obtained. 4.6.2. Case #2: No Match Found, Name Association Cached If the client does not find a presented identifier matching any of the = reference identifiers, but has previously associated one of the = reference identifiers with the certificate (a) by a human user during a = previous interaction with this application service or (b) via = configuration settings, the server identity check succeeds. The cached = name association needs to include the certificate presented and the = context in which in which it was accepted. The context includes the = chain of certificates from the presented certificate to the trust = anchor. >=20 > > and the "cached certificate" > > ought to be clarified to mean memorized "CERT-ID" reference = identifier > > to make it clearly distinct from anything related to TLS session = caching. I don't any any big issues here with the word cached. Although you = might want to use "cached name association" >=20 > 1. How about changing "cached certificate" to "stored certificate" or > "memorized certificate"? I agree that the term "caching" might be = confusing to > some folks. >=20 > 2. Are you suggesting that we change "cached certificate" to "stored = reference > identifier"? That doesn't strike me as a helpful change because it = doesn't make > clear that the client needs to keep track of more than just the = reference > identifier, it needs to store an association between the verified = reference > identifier (im.example.com or > whatever) and the certificate that was presented by the server it = connected to > for that DNS domain name (or, at the very least, a hash of the = certificate). >=20 > > Jim Schaad wrote: > >> > >> Martin Rex wrote: > >>> > >>> (1) lack of rationale why the cert chain should be cached > >>> rather than only the server certificate > >>> > >>> I think that (1) is seriously underspecified. With the existing > >>> matching procedure, caching the entire cert chain does NOT make = any > >>> sense at all (and does not provide security benefit). > >> > >> I look upon section 4.6.2 (and follows) to be analogous to the user > >> adding an additional SAN to a certificate that states that one or > >> more of the reference identifiers is being bound to a certificate. > >> As an advanced user, I may still wish some correct path validation = to occur. > >> > >> Example [...] > > > > > > Given your example, which admittedly I have difficulty = understanding, > > I firmly believe the use of the term "cached server cert (chain)" > > is throroughly underspecified in server-id-check and should be fixed > > and all existing references to "certificate path validation" > > should be removed. > > > > The concept of "caching" implies to shortcut or skip operations and > > rely on previous results of the same operation (e.g. network > > round-trips, network bandwidth, computational overhead like > > PK-crypto-operations or other resource-intensive operations such as > > OCSP-requests or CRL-downloads&checking). > > > > The TLS protocol contains a feature called "TLS session caching", = and > > when used, it normally "saves" not only the PK-crypto-operations for > > the TLS key exchange (which may be a single PK-crypto operation for > > each peer for RSA ciphersuites), but also the entire certificate = path > > validation (which usually involves several PK-crypto-operations plus > > OCSP-requests and CRL-downloads with third parties). > > > > As specified in all existing TLS protocol specs, last sentence of > > section 1, the interpretation of peer certificates is entirely up to > > the calling application on top of TLS. It is also completely up to > > the application to decide whether to abort a TLS handshake when PKIX > > certificate path validation can not be performed for the peer > > certificate due to a lack of trust. > > > > server-id-check is an operation that is performed after the TLS > > handshake has completed, and the peer certificate can be obtained = from > > the TLS stack, independent of whether the TLS session was resumed = from > > the cache (and certificate path validation skipped) or a full TLS > > handshake was perfomed. > > > > "Pinning" of the server certificate means, that server-id-check is > > substituted with a comparison of the server's end-entity cert, like = a > > "CERT-ID" reference identifier. The "pinned" server cert must be > > memorized by the application "somewhere", along with the > > meta-information for which hostname / reference-identifier the = pinning > > applies and whether PKIX cert validation succeeded on this > > certificate. There is no security problem with allowing CERT-ID > > matching for certificate chains for which no certificate path > > validation can be performed due to a lack of trust. > > > > This is what this paragraph of rfc-2818 is about: > > > > If the client has external information as to the expected = identity of > > the server, the hostname check MAY be omitted. (For instance, a > > client may be connecting to a machine whose address and hostname = are > > dynamic but the client knows the certificate that the server will > > present.) > > > > A users decision to "pin" a server cert may involve consideration of > > chain certificates in case that PKIX certificate path validation > > succeeded. But memorizing anything besides the server cert will = *NOT* > > provide any security benefit for future automated server endpoint > > identifications and is unnecessary. >=20 > Aha, I see your point now. Thanks for explaining it in more detail. >=20 > > If the server-id-check document wants to define a CERT-ID reference > > identifier and use the term "caching", is should use it in a fashion > > that there is no confusion with the TLS session caching and that the > > PKIX certificate path validation usually performed by TLS on behalf = of > > the calling app (but only during full TLS handshakes) is independent > > from application-level server-id-check, independent of whether = DNS-ID, > > URL-ID, SRV-ID, CN-ID or CERT-ID is used. > > > > One should be very careful about the use of the term "caching" > > in server-id-check so that there is no confusion with anything from > > the TLS session caching. >=20 > Yes, point taken. >=20 > > For server-id-check "caching" applies > > only to the decision to use the server end-entity cert as the > > reference identifier ("CERT-ID") for a specific target, >=20 > In the terms of this I-D, a certificate is not a reference identifier. > The reference identifier is still a DNS-ID or whatever, it's just that = after pinning > the client considers it acceptable to use as a reference identifier a = DNS domain > name that was presented in the server's certificate during a previous > connection attempt and explicitly accepted by a human user (as long as = the > memorized certificate doesn't change in future connection attempts = etc.). >=20 > > instead > > of deriving reference identifiers such as DNS-ID, URL-ID or CN-ID = from > > the target's hostname that was used to establish the communication > > channel. This decision could be a result of user-interaction or > > result of a configuration to that effect. >=20 > Correct. >=20 > > Btw. I would be extremely careful about visualizing chain = certificates > > to Joe Average user for a chain that failed certificate path > > validation because it is quite undefined how many checks were really = skipped. > > You do NOT want to have Joe Average user perform an eyeball = comparison > > on the cert or public key fingerprint on the top-level cert at the = end > > of a cert chain for which certificate path validation failed and let > > him assume this makes it a successfull path validation. >=20 > Yes, applications need to be extremely careful about presenting = anything to Joe > Average or Barry's Mother or other unsophisticated individuals. >=20 > > Given how certificate path validation is specified by PKIX = (rfc-5280, > > section 6), working from the trust anchor downwards, no signature > > checks, no constraints checks and not revocation checks are = performed > > on an untrusted chain. >=20 > Noted. >=20 > Peter >=20 > -- > Peter Saint-Andre > https://stpeter.im/ From stpeter@stpeter.im Wed Oct 6 13:52:28 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37F4B3A71D3; Wed, 6 Oct 2010 13:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 urC8bNrTaM2f; Wed, 6 Oct 2010 13:52:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 001FE3A723E; Wed, 6 Oct 2010 13:52:26 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E7CA440074; Wed, 6 Oct 2010 14:59:37 -0600 (MDT) Message-ID: <4CACE1C4.3000101@stpeter.im> Date: Wed, 06 Oct 2010 14:53:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: "Henry B. Hotz" References: <4C9A382F.80501@stpeter.im> <52B5123E-208D-44B6-BB95-92D5B44D4654@jpl.nasa.gov> In-Reply-To: <52B5123E-208D-44B6-BB95-92D5B44D4654@jpl.nasa.gov> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "ietf@ietf.org" , "certid@ietf.org" , "tls@ietf.org" , Wes Hardaker Subject: Re: [certid] review of draft-saintandre-tls-server-id-check-09 X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 20:52:28 -0000 Sorry about the delayed reply, still catching up on list traffic here... On 9/22/10 4:11 PM, Henry B. Hotz wrote: > > On Sep 22, 2010, at 10:09 AM, Peter Saint-Andre wrote: > >> 2. A human user has explicitly agreed to trust a service that >> provides mappings of source domains to target domains, such as a >> dedicated discovery service or an identity service that securely >> redirects requests from the source domain to a target domain >> (however, such an arrangement is not encouraged and if a client >> supports such a service then it needs to disable it by default and >> carefully warn the user about the possible negative consequences of >> trusting such a service). > > > Pure wordsmithing. Make sure this still says what you want: > > 2. A human user has explicitly agreed to trust a service that > provides mapping of source domains to target domains. For example > the user may trust a dedicated discovery service or identity service > that securely redirects requests from the source to a target domain. > > > Such an arrangement is not encouraged. If a client supports such a > service then it needs to disable it by default, and it MUST carefully > warn the user about the possible negative consequences of trusting > such a service. Just to close the loop, I think we had agreement to remove that paragraph, so no further wordsmithing required. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Oct 6 14:47:47 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7894B3A713F for ; Wed, 6 Oct 2010 14:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, 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 f1Huw7XHuLsc for ; Wed, 6 Oct 2010 14:47:45 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4FBF33A70FA for ; Wed, 6 Oct 2010 14:47:45 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 27C8C40074 for ; Wed, 6 Oct 2010 15:54:57 -0600 (MDT) Message-ID: <4CACEEBC.8010109@stpeter.im> Date: Wed, 06 Oct 2010 15:48:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 21:47:47 -0000 I'm reading through the mailing list threads and working to identity the remaining open issues. Jeff and I might post additional, focused requests for feedback in the near future, so stay tuned. However, I think that our working copy addresses nearly all the feedback that's been posted during and after the IETF Last Call, so we plan to publish a revised I-D as soon as possible. This message covers the open issue of wildcard matching, specifically matching of component fragments (e.g., foo*.example.com). RFC 2818 states: Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. Version -01 of draft-saintandre-tls-server-id-check (August 31, 2009) had this text: A dNSName MAY contain the wildcard character '*' (ASCII 42). The wildcard character applies only to the left-most (least significant) domain name component or component fragment and matches any single component or component fragment. For instance, a dNSName of *.example.com matches foo.example.com but not bar.foo.example.com or example.com itself; similarly, a dNSName of baz*.example.net matches baz1.example.net and baz2.example.net but not qux.example.net or example.net itself. Version -02 of draft-saintandre-tls-server-id-check (October 2, 2009) had this modified text: Unless otherwise specified by an application protocol, the dNSName MAY contain one instance of the wildcard character '*'. The wildcard character applies only to the left-most domain name component and matches any single component (thus a dNSName of *.example.com matches foo.example.com but not bar.foo.example.com or example.com itself). The wildcard character is not allowed in component fragments (thus a dNSName of baz*.example.net is not allowed and shall not be taken to match baz1.example.net and baz2.example.net). And version -09 has similar text: A client employing this specification's rules MAY match the reference identifier against a presented identifier containing one instance of the wildcard character '*', but only as the left-most label of the domain name, e.g. *.example.com (following the definition of "label" from [DNS]). If such a wildcard identifier is presented, the wildcard MUST be used to match only the one position-wise corresponding label (thus *.example.com matches foo.example.com but not bar.foo.example.com or example.com). The client MUST fail to match a presented identifier in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net), or in which the wildcard character does not comprise the left-most label in the presented identifier (e.g., neither bar.*.example.net nor bar.f*o.example.net are allowed). If I recall correctly, I added that the rule against matching of component fragments in response to feedback from Alexey Melnikov, who was reporting on discussion within the IESG, perhaps regarding draft-ietf-sip-domain-certs (now RFC 5922), which states: ### Implementations MUST NOT match any form of wildcard, such as a leading "." or "*." with any other DNS label or sequence of labels. For example, "*.example.com" matches only "*.example.com" but not "foo.example.com". Similarly, ".example.com" matches only ".example.com", and does not match "foo.example.com". RFC 2818 [7] (HTTP over TLS) allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". RFC 5280 [6], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. RFC 3261 [2] does not provide any guidelines on the presence of wildcards in certificates. Through the rule above, this document prohibits such wildcards in certificates for SIP domains. ### On the topic of wildcard matching, Martin Rex posted as follows on September 16... ### (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net) This is in clear contradiction to the wildcard matching specified in rfc-2818 Section 3.1. And without any rationale for this U-Turn, that seems to be entirely inappropriate for a BCP. In my implementation of RFC-2818 wildcard matching, I deliberately ignore DNS names that contain more than one wildcard character, have a wildcard character in different but the leftmost label or have a wildcard character and less than 3 DNS labels. But I certainly do the substring match specified in rfc-2818 and I'm not going to remove the substring match from my implementation without a convincing rationale... What exactly is the benefit of allowing a full wildcard match but prohibiting a partial/substring wildcard match of the leftmost label? ### Martin Rex also posted as follows in that same thread: ### Partial wildcard match will allow you to use one single server cert for a server farm behind a load-balancing NAT with hostnames such as "www1.example.com", "www2.example.com", ... "wwwNN.,example.com" by using the pattern "www*.example.com" that will neither match "kdc.example.com", "ldap.example.com", nor "imap.example.com" To me, that seems significantly more useful than only a full wildcard match. The current draft could be read to mean (without a single word of rationale) that partial wildcard matching is so much more dangerous than full wildcard matching that MUST NOT be used by anyone anymore. If this is not removed from the draft, this will result in a completely inconsistent behaviour within the installed based causing headaches with no ends to end-users, admins and helpdesks--for those servers that actively use this sensible alternative to full wildcard certs as specified in rfc-2818. ### What is the sense of this list regarding wildcard matching on component fragments? Martin has made his arguments so I'm especially interested in feedback from other folks. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From ark@eltex.net Thu Oct 7 05:56:57 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28E03A6E6F for ; Thu, 7 Oct 2010 05:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 tFRKbp6H7jcQ for ; Thu, 7 Oct 2010 05:56:56 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id E79D93A6D27 for ; Thu, 7 Oct 2010 05:56:55 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o97CvtQW002859; Thu, 7 Oct 2010 16:57:55 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o97Cvshw007302; Thu, 7 Oct 2010 16:57:54 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Thu, 7 Oct 2010 16:57:54 +0400 From: ArkanoiD To: Peter Saint-Andre Message-ID: <20101007125754.GA11638@eltex.net> References: <4CACEEBC.8010109@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4CACEEBC.8010109@stpeter.im> User-Agent: Mutt/1.4.2.3i Cc: IETF cert-based identity Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 12:56:57 -0000 Are there any such certificates "in the wild"? Do current clients support it? If there aren't any and it is not supported anyways, let's keep status quo and do not make things more complicated than needed. For www1, www2 etc one may use extra name component and that's all. On Wed, Oct 06, 2010 at 03:48:44PM -0600, Peter Saint-Andre wrote: > > (e.g., baz*.example.net is not allowed and MUST NOT be taken to match > baz1.example.net and baz2.example.net) > > This is in clear contradiction to the wildcard matching specified > in rfc-2818 Section 3.1. And without any rationale for this U-Turn, > that seems to be entirely inappropriate for a BCP. > From stpeter@stpeter.im Thu Oct 7 13:43:17 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477F73A7111 for ; Thu, 7 Oct 2010 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, 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 Sx8c59m30nhE for ; Thu, 7 Oct 2010 13:43:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 112503A6EED for ; Thu, 7 Oct 2010 13:43:16 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C2F1400EE; Thu, 7 Oct 2010 14:50:35 -0600 (MDT) Message-ID: <4CAE3122.9080504@stpeter.im> Date: Thu, 07 Oct 2010 14:44:18 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: ArkanoiD References: <4CACEEBC.8010109@stpeter.im> <20101007125754.GA11638@eltex.net> In-Reply-To: <20101007125754.GA11638@eltex.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 20:43:17 -0000 On 10/7/10 6:57 AM, ArkanoiD wrote: > Are there any such certificates "in the wild"? Do current clients > support it? If there aren't any and it is not supported anyways, > let's keep status quo and do not make things more complicated than > needed. For www1, www2 etc one may use extra name component and > that's all. What do you mean by "the status quo" -- the text in version -09 of the server-id-check I-D (no wildcard in component fragments, like foo*) or the text in RFC 2818 and several other specs (*oo and f*o and foo* are fine)? As far as I can see, allowing wildcards in component fragments makes things more complicated than needed because a CA needs to have more complex rules for issuance and a TLS library or application client needs to have a more complex parsing algorithm (checking for things like *oo.example.com and foo*.example.com and f*o.example.com instead of just *.example.com -- it's also not clear to me from RFC 2818 if multiple instances of the wildcard character are allowed, such that f*b*r.example.com would be acceptable). Allowing '*' only as the complete left-most label seems easier to me (and I've received feedback to that effect off-list, as well). Peter -- Peter Saint-Andre https://stpeter.im/ From ark@eltex.net Thu Oct 7 14:11:33 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA58B3A7180 for ; Thu, 7 Oct 2010 14:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 Ef1tK7DLOzm3 for ; Thu, 7 Oct 2010 14:11:27 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id 9B85E3A7182 for ; Thu, 7 Oct 2010 14:11:23 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o97LC8kt031441; Fri, 8 Oct 2010 01:12:09 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o97LC8iO004333; Fri, 8 Oct 2010 01:12:08 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Fri, 8 Oct 2010 01:12:08 +0400 From: ArkanoiD To: Peter Saint-Andre Message-ID: <20101007211208.GA9771@eltex.net> References: <4CACEEBC.8010109@stpeter.im> <20101007125754.GA11638@eltex.net> <4CAE3122.9080504@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4CAE3122.9080504@stpeter.im> User-Agent: Mutt/1.4.2.3i Cc: IETF cert-based identity Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:11:34 -0000 On Thu, Oct 07, 2010 at 02:44:18PM -0600, Peter Saint-Andre wrote: > On 10/7/10 6:57 AM, ArkanoiD wrote: > > Are there any such certificates "in the wild"? Do current clients > > support it? If there aren't any and it is not supported anyways, > > let's keep status quo and do not make things more complicated than > > needed. For www1, www2 etc one may use extra name component and > > that's all. > > What do you mean by "the status quo" -- the text in version -09 of the > server-id-check I-D (no wildcard in component fragments, like foo*) or > the text in RFC 2818 and several other specs (*oo and f*o and foo* are > fine)? I mean current implementations and already issued certificates. > As far as I can see, allowing wildcards in component fragments makes > things more complicated than needed because a CA needs to have more > complex rules for issuance and a TLS library or application client needs > to have a more complex parsing algorithm (checking for things like > *oo.example.com and foo*.example.com and f*o.example.com instead of just > *.example.com -- it's also not clear to me from RFC 2818 if multiple > instances of the wildcard character are allowed, such that > f*b*r.example.com would be acceptable). Allowing '*' only as the > complete left-most label seems easier to me (and I've received feedback > to that effect off-list, as well). It was my primary concern too, i definitely prefer simple and straightforward parsers that are less likely to behave any unexpected way :-) Once we agree to implement complex parsing, someone almost certainly will just use his favourite regexp library just because it saves time (causing total havoc) ;-) From stpeter@stpeter.im Thu Oct 7 14:26:03 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B961F3A715C for ; Thu, 7 Oct 2010 14:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 jEDseEvZlsVH for ; Thu, 7 Oct 2010 14:26:02 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id B10E13A719A for ; Thu, 7 Oct 2010 14:25:21 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2EDFF40077; Thu, 7 Oct 2010 15:32:41 -0600 (MDT) Message-ID: <4CAE3AFF.9020804@stpeter.im> Date: Thu, 07 Oct 2010 15:26:23 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: ArkanoiD References: <4CACEEBC.8010109@stpeter.im> <20101007125754.GA11638@eltex.net> <4CAE3122.9080504@stpeter.im> <20101007211208.GA9771@eltex.net> In-Reply-To: <20101007211208.GA9771@eltex.net> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:26:03 -0000 On 10/7/10 3:12 PM, ArkanoiD wrote: > On Thu, Oct 07, 2010 at 02:44:18PM -0600, Peter Saint-Andre wrote: >> On 10/7/10 6:57 AM, ArkanoiD wrote: >>> Are there any such certificates "in the wild"? Do current >>> clients support it? If there aren't any and it is not supported >>> anyways, let's keep status quo and do not make things more >>> complicated than needed. For www1, www2 etc one may use extra >>> name component and that's all. >> >> What do you mean by "the status quo" -- the text in version -09 of >> the server-id-check I-D (no wildcard in component fragments, like >> foo*) or the text in RFC 2818 and several other specs (*oo and f*o >> and foo* are fine)? > > I mean current implementations and already issued certificates. > >> As far as I can see, allowing wildcards in component fragments >> makes things more complicated than needed because a CA needs to >> have more complex rules for issuance and a TLS library or >> application client needs to have a more complex parsing algorithm >> (checking for things like *oo.example.com and foo*.example.com and >> f*o.example.com instead of just *.example.com -- it's also not >> clear to me from RFC 2818 if multiple instances of the wildcard >> character are allowed, such that f*b*r.example.com would be >> acceptable). Allowing '*' only as the complete left-most label >> seems easier to me (and I've received feedback to that effect >> off-list, as well). > > It was my primary concern too, i definitely prefer simple and > straightforward parsers that are less likely to behave any unexpected > way :-) Once we agree to implement complex parsing, someone almost > certainly will just use his favourite regexp library just because it > saves time (causing total havoc) ;-) Exactly. The intended status of this document is BCP = Best Current Practice. That "B" is in there for a reason. The question is: does allowing *oo and f*o and foo* (and maybe even f*b*r) as wildcard fragments truly represent a "best" current practice, or only "current" practice? It doesn't strike me as a most excellent, effective, desirable, suitable, appropriate, or useful practice, although I freely grant that it is in common and general use at the present time. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Thu Oct 7 14:47:26 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCA493A6E7D for ; Thu, 7 Oct 2010 14:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 nm6tWiZubKWf for ; Thu, 7 Oct 2010 14:47:25 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 984AF3A6D53 for ; Thu, 7 Oct 2010 14:47:25 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D5518403DF; Thu, 7 Oct 2010 15:54:44 -0600 (MDT) Message-ID: <4CAE402A.30707@stpeter.im> Date: Thu, 07 Oct 2010 15:48:26 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Jim Schaad References: <201010051747.o95Hl8iZ002597@fs4113.wdf.sap.corp> <4CACACEF.6050205@stpeter.im> <009c01cb6590$b47e4060$1d7ac120$@augustcellars.com> In-Reply-To: <009c01cb6590$b47e4060$1d7ac120$@augustcellars.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Oct 2010 21:47:27 -0000 On 10/6/10 1:57 PM, Jim Schaad wrote: > > >> -----Original Message----- From: Peter Saint-Andre >> [mailto:stpeter@stpeter.im] Sent: Wednesday, October 06, 2010 10:08 >> AM To: mrex@sap.com Cc: Jim Schaad; matt@mattmccutchen.net; >> certid@ietf.org Subject: Re: [certid] section 4.6 rewrite (aka: Bad >> certificate handling) >> >> On 10/5/10 11:47 AM, Martin Rex wrote: >>> Jim Schaad wrote: >>>> >>>> Martin Rex wrote: >>>>> >>>>> (2) support for server certs that do not succeed certificate >>>>> path validation to one of the (pre-)configured trust anchors >>>> >>>> This is from the abstract of the document in question: >>>> >>>> "This document specifies best current practices for >>>> representing and verifying the identity of application services >>>> in such interactions." >>>> >>>> As you see the document is about how to do name comparisons. >>>> If you believe a document on trust , path validation and >>>> pinning are needed I would strongly suggest that you write such >>>> a draft. >>> >>> Thanks! I was asking for removal of the reference to path >>> validation from that one paragraph: >>> >>> PeterSA wrote: >>>> >>>> then the client MUST verify that the presented certificate is >>>> the same as the cached certificate, including verification of >>>> the entire certification path. >>> >>> So the "including verification of the entire certification path" >>> should be completely removed, >> >> I'd be curious to see what Jim's feedback is on that point, since >> he suggested the inclusion of text about the certification path. > > I don't care if you remove the word verification. What I want to say > is that the presented certificate and it's chain back to the trust > anchor is the same as when it was first checked by the advanced user. > If the path has changed then the answer should be re-obtained. > > > 4.6.2. Case #2: No Match Found, Name Association Cached > > If the client does not find a presented identifier matching any of > the reference identifiers, but has previously associated one of the > reference identifiers with the certificate (a) by a human user during > a previous interaction with this application service or (b) via > configuration settings, the server identity check succeeds. The > cached name association needs to include the certificate presented > and the context in which in which it was accepted. The context > includes the chain of certificates from the presented certificate to > the trust anchor. That seems better. Thanks for the proposed text. Tweaked slightly in our working copy, as follows: If the client does not find a presented identifier matching any of the reference identifiers, but has previously associated one of the reference identifiers with the certificate (a) because of positive acceptance by a human user during a previous interaction with this application service or (b) because of configuration settings, then the server identity check succeeds. The cached name association needs to take account of both the certificate presented and the context in which it was accepted or configured (where the context includes the chain of certificates from the presented certificate to the trust anchor). >>> and the "cached certificate" ought to be clarified to mean >>> memorized "CERT-ID" reference identifier to make it clearly >>> distinct from anything related to TLS session caching. > > I don't any any big issues here with the word cached. Although you > might want to use "cached name association" Yes, I like that phrase. Peter -- Peter Saint-Andre https://stpeter.im/ From mrex@sap.com Thu Oct 7 17:45:44 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1467F3A63C9 for ; Thu, 7 Oct 2010 17:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.859 X-Spam-Level: X-Spam-Status: No, score=-9.859 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 aJo-xUd4BBA1 for ; Thu, 7 Oct 2010 17:45:34 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 7FFD43A63D3 for ; Thu, 7 Oct 2010 17:45:31 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o980kDJq026583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2010 02:46:13 +0200 (MEST) From: Martin Rex Message-Id: <201010080045.o980jeg1018391@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Fri, 8 Oct 2010 02:45:40 +0200 (MEST) In-Reply-To: <4CAE3AFF.9020804@stpeter.im> from "Peter Saint-Andre" at Oct 7, 10 03:26:23 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 00:45:44 -0000 Peter Saint-Andre wrote: > > On 10/7/10 3:12 PM, ArkanoiD wrote: > > > > It was my primary concern too, i definitely prefer simple and > > straightforward parsers that are less likely to behave any unexpected > > way :-) Once we agree to implement complex parsing, someone almost > > certainly will just use his favourite regexp library just because it > > saves time (causing total havoc) ;-) > > Exactly. Full agreement. It is fine with me to cut sharp down to that functionality that rfc-2818 described and illustrated 10 years ago. But I believe it is not appropriate to turn an rfc-2818 effective SHOULD into a MUST NOT within a BCP unless there is a REALLY REALLY REALLY good rationale for it. I would be OK with deprecating it (SHOULD NOT). Personally, I do not see any problems implementing exactly the examples given in rfc-2818, but not more (i.e. single-wildcard substring matching on the leftmost label only). btw. "f*.com" is an rfc-2818 example that _my_ implementation of rfc-2818 matching unconditionally ignores when found in CN-ID or DNS-ID of a server cert--I require at least 3 labels when a wildcard is used. Should server-id-check promote "*.com" matching? (I think it should not). -Martin From matt@mattmccutchen.net Thu Oct 7 18:11:24 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F8103A659A for ; Thu, 7 Oct 2010 18:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] 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 1+uwqG+jWvS1 for ; Thu, 7 Oct 2010 18:11:21 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id C49CC3A6767 for ; Thu, 7 Oct 2010 18:11:16 -0700 (PDT) Received: from homiemail-a3.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTP id 5A5D0284076; Thu, 7 Oct 2010 18:12:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=nTVHkhkdjzVi7a0SFRdPk5ykbBghFBauiUvjzytSUXh Fb2/1z6DUWtNkODjeNcszF2kjCE39nrR2vzrusUWteDHpprZdxaK9oGZ/noDY0hy wwKVrOq0Kvbu9qZTSCW4A4AOU02RVQE3pR/oZvXwR/RN6qjlKHzGP61AkQzdlxG4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=kUUeK0hGq/sjBrcwK2jZjJ4zfMQ=; b=DqPW5+QONs y2sc8obe14IczIcbdMUSlPakFsYyCCvuNXDn5QWDZwbN8mz02DTtidHxZQp5PQDi XMw+mcUBVSmiTPs4J+VCW1kT1uuwiAwfP/2Z0HCg8XHyHtCLU5MqlIKUu5kufR6j Dzm17Eu4wVcV5ZHnutEpPLH4pwvUVeH9g= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a3.g.dreamhost.com (Postfix) with ESMTPA id 04B7828406C; Thu, 7 Oct 2010 18:12:19 -0700 (PDT) From: Matt McCutchen To: mrex@sap.com In-Reply-To: <201010080045.o980jeg1018391@fs4113.wdf.sap.corp> References: <201010080045.o980jeg1018391@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Oct 2010 21:12:18 -0400 Message-ID: <1286500338.1912.39.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 01:11:24 -0000 On Fri, 2010-10-08 at 02:45 +0200, Martin Rex wrote: > btw. "f*.com" is an rfc-2818 example that _my_ implementation of rfc-2818 > matching unconditionally ignores when found in CN-ID or DNS-ID of a > server cert--I require at least 3 labels when a wildcard is used. > Should server-id-check promote "*.com" matching? (I think it should not). The document does not "promote" the interpretation of "*.com" as a wildcard, it just declines to make a special case to forbid it. In any case, I don't see anything wrong with allowing such matching at the server-id-check level. CAs are responsible for not giving an entity a certificate that matches names the entity does not own. -- Matt From matt@mattmccutchen.net Thu Oct 7 18:16:09 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6995B3A6768 for ; Thu, 7 Oct 2010 18:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] 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 Abg39kHyW23P for ; Thu, 7 Oct 2010 18:16:07 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id C90B43A63D3 for ; Thu, 7 Oct 2010 18:16:07 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 8910859806C; Thu, 7 Oct 2010 18:17:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=rvVO7wDxBDvLeLDWWw8gsX6qRSbG7GgLmdzV7eXldEv pJKFUP0jFL+d3jjcK+Qg0oX49pKR/YA0VyfdOk8nwL48M5KGDnba3vZR5CD6VZu3 2Rdvmbdn/zesyLOZt0AIRofF2Dw534luweEq1eVG8rVHuZsUIa3XrJmECV9JJuK4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=Q3RCxOrsaiuojuaDyTH4Vqh4E9Y=; b=ImTbGITw5t 7+aJRRFATz/DotK3lMimJKYdfYsGACwujPzjN7iTCnY2tNFze27yBv9ISHCuRV+l Cu6b8zpVvvs0wVaJWTH8KytRmt2RUmfucPJq4evDv/rKiSUn37qfrGT/56TGx/Ks XWLvye+TeQyNvAmzWWQKD2UbJIZ0+eBmE= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id 4587B598069; Thu, 7 Oct 2010 18:17:11 -0700 (PDT) From: Matt McCutchen To: Peter Saint-Andre In-Reply-To: <4CAE3AFF.9020804@stpeter.im> References: <4CACEEBC.8010109@stpeter.im> <20101007125754.GA11638@eltex.net> <4CAE3122.9080504@stpeter.im> <20101007211208.GA9771@eltex.net> <4CAE3AFF.9020804@stpeter.im> Content-Type: text/plain; charset="UTF-8" Date: Thu, 07 Oct 2010 21:17:10 -0400 Message-ID: <1286500630.1912.43.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 01:16:09 -0000 On Thu, 2010-10-07 at 15:26 -0600, Peter Saint-Andre wrote: > The intended status of this document is BCP = Best Current Practice. > That "B" is in there for a reason. The question is: does allowing *oo > and f*o and foo* (and maybe even f*b*r) as wildcard fragments truly > represent a "best" current practice, or only "current" practice? It > doesn't strike me as a most excellent, effective, desirable, suitable, > appropriate, or useful practice, although I freely grant that it is in > common and general use at the present time. Is it? I have never seen a certificate with a wildcard that is not a whole label on a public web site. -- Matt From mrex@sap.com Thu Oct 7 18:40:54 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD3F3A67A3 for ; Thu, 7 Oct 2010 18:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.863 X-Spam-Level: X-Spam-Status: No, score=-9.863 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 ufBewRZVZ9-t for ; Thu, 7 Oct 2010 18:40:46 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 7DBFC3A679F for ; Thu, 7 Oct 2010 18:40:45 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o981fmMR008560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2010 03:41:48 +0200 (MEST) From: Martin Rex Message-Id: <201010080141.o981fldO021621@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 8 Oct 2010 03:41:47 +0200 (MEST) In-Reply-To: <1286500630.1912.43.camel@mattlaptop2.local> from "Matt McCutchen" at Oct 7, 10 09:17:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 01:40:54 -0000 Matt McCutchen wrote: > > On Thu, 2010-10-07 at 15:26 -0600, Peter Saint-Andre wrote: > > The intended status of this document is BCP = Best Current Practice. > > That "B" is in there for a reason. The question is: does allowing *oo > > and f*o and foo* (and maybe even f*b*r) as wildcard fragments truly > > represent a "best" current practice, or only "current" practice? It > > doesn't strike me as a most excellent, effective, desirable, suitable, > > appropriate, or useful practice, although I freely grant that it is in > > common and general use at the present time. > > I have never seen a certificate with a wildcard that is not a > whole label on a public web site. The idea behind writing documents such as rfc-2818 is, that implementers don't have to do public opinion polls an apply heuristics, but instead follow the implementation guidelines in the document. It is pretty obvious that rfc-2818 meant to standardize substring wildcard matching with a single wildcard character in the leftmost dns label. What is _not_ clear, is whether rfc-2818 meant to also allow more than one wildcard character in a CN-ID or DNS-ID, wildcards in more than one DNS label or wildcards in other than the leftmost label. I believe that shipping a TLS client that matches a server cert with CN-ID or DNS-ID equal to "*.*.com" is neither reasonable nor responsible, and it I don't care whether a negilgent CA issued such a certificate on purpose or whether an attacker managed to get such a cert issued--there were two bugs published that made this possible: OID integer wraparound and embedded NUL chars in the Subject DName, and a significant part of the installed base does not check server certs for revocation (MSIE on XP/2003). (The folks on domains such as "*.co.uk" or "*.co.tw" are in a slightly more difficult position). -Martin From mrex@sap.com Thu Oct 7 18:59:08 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05033A6781 for ; Thu, 7 Oct 2010 18:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.867 X-Spam-Level: X-Spam-Status: No, score=-9.867 tagged_above=-999 required=5 tests=[AWL=0.382, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 CPgCSbYKhLdQ for ; Thu, 7 Oct 2010 18:59:07 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 2349D3A677D for ; Thu, 7 Oct 2010 18:59:06 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o98209dM010900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2010 04:00:09 +0200 (MEST) From: Martin Rex Message-Id: <201010080200.o98208QR022569@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Fri, 8 Oct 2010 04:00:08 +0200 (MEST) In-Reply-To: <1286500630.1912.43.camel@mattlaptop2.local> from "Matt McCutchen" at Oct 7, 10 09:17:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 01:59:09 -0000 Matt McCutchen wrote: > > I have never seen a certificate with a wildcard that is not a > whole label on a public web site. Btw. the use of TLS is not limited to the public internet. I don't think that know which _public_ website uses this is meaningless. The matching is implemented on the client anyway, not on the server. A much more interesting question would be, what exact kind of wildcard matching do popular TLS clients actually implement? - Microsoft SChannel on XP/2003, Vista/Win7 - Firefox 3.x - Google Chrome - Apple Safari (non-Windows) - Opera We started shipping SSL with our app in 2000/2001. Back then, I noticed that MSIE 5.0x implemented (full-label) wildcard matching (i.e. WinNT 4 and Win9x/ME), but SChannel in Windows 2000 and therefore MSIE 5.0x on Windows 2000 did _NOT_ implement wildcard matching. For internal testing, I've been using server certs with wildcard CN-IDs since 2000, but not being aware of the wildcards substring matching described in rfc2818 back then, I never tried that myself. I did issue server certs for wildcard substring matching when I implemented rfc-2818, though -- and I consider it likely that other implementors did this as well. -Martin From Jeff.Hodges@KingsMountain.com Fri Oct 8 14:08:54 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFFB93A695D for ; Fri, 8 Oct 2010 14:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.148 X-Spam-Level: X-Spam-Status: No, score=-102.148 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 KbaoFUocFZw7 for ; Fri, 8 Oct 2010 14:08:53 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 9C1DE3A6952 for ; Fri, 8 Oct 2010 14:08:53 -0700 (PDT) Received: (qmail 16036 invoked by uid 0); 8 Oct 2010 21:09:59 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 8 Oct 2010 21:09:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=CCsEeIPNCPTm5GZ3C+hv53ypjYIoyxmCKLxlKA3dOlTwAs28CbRZvBO/ne+WQvlOm5NeZqpsAb7kaXzJPptP9ScLnoDTWmEunE+jJEnZP4Yf9xbMS3ftVEV+rrrfN1og; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P4KCU-0008U2-W7 for certid@ietf.org; Fri, 08 Oct 2010 15:09:59 -0600 Message-ID: <4CAF88A5.4030205@KingsMountain.com> Date: Fri, 08 Oct 2010 14:09:57 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] fyi: assessment of present compatibility of CN-ID, DNS-ID (SAN:dNSName) by Paul Tiemann (digicert) (was: Need to define "most specific, RDN") X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2010 21:08:54 -0000 Peter Saint-Andre said > > Jeff, what is your take? Here's what I see... Agreed, i think the draft addresses those points. =JeffH From stpeter@stpeter.im Mon Oct 11 11:42:22 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE24B3A6B57 for ; Mon, 11 Oct 2010 11:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.724 X-Spam-Level: X-Spam-Status: No, score=-101.724 tagged_above=-999 required=5 tests=[AWL=-0.791, BAYES_00=-2.599, SARE_FWDLOOK=1.666, 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 eRN72STb4JBb for ; Mon, 11 Oct 2010 11:42:20 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 579583A6B52 for ; Mon, 11 Oct 2010 11:42:20 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DE07B403DF; Mon, 11 Oct 2010 12:50:09 -0600 (MDT) Message-ID: <4CB35AD1.1060808@stpeter.im> Date: Mon, 11 Oct 2010 12:43:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mrex@sap.com References: <201010080200.o98208QR022569@fs4113.wdf.sap.corp> In-Reply-To: <201010080200.o98208QR022569@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 18:42:22 -0000 On 10/7/10 8:00 PM, Martin Rex wrote: > Matt McCutchen wrote: >> >> I have never seen a certificate with a wildcard that is not a >> whole label on a public web site. > > Btw. the use of TLS is not limited to the public internet. I don't think anyone said it is. However, it's difficult for researchers to do much testing of sites that are closed off from the public internet, so that's the real-world data that folks tend to mention. Speaking of which, someone contacted Jeff and me off-list about some research results showing that of a very large number of certificates presented by TLS-protected websites, less than 0.01% contain wildcards in component fragments. Given that minuscule level of deployment, I don't see good reasons to spend more cycles on the topic. > I don't think that know which _public_ website uses this is meaningless. > The matching is implemented on the client anyway, not on the server. Yes it is, but requiring significantly more complex matching to handle less than 0.01% of the issued certificates seems like a bad idea, i.e., not a *best* current practice. > A much more interesting question would be, what exact kind of wildcard > matching do popular TLS clients actually implement? Why is that a much more interesting question? > - Microsoft SChannel on XP/2003, Vista/Win7 > - Firefox 3.x > - Google Chrome > - Apple Safari (non-Windows) > - Opera > > We started shipping SSL with our app in 2000/2001. Back then, > I noticed that MSIE 5.0x implemented (full-label) wildcard matching > (i.e. WinNT 4 and Win9x/ME), but SChannel in Windows 2000 and therefore > MSIE 5.0x on Windows 2000 did _NOT_ implement wildcard matching. > For internal testing, I've been using server certs with wildcard CN-IDs > since 2000, but not being aware of the wildcards substring matching > described in rfc2818 back then, I never tried that myself. > > I did issue server certs for wildcard substring matching when I > implemented rfc-2818, though -- and I consider it likely that other > implementors did this as well. That's nice, but not directly relevant to the current discussion because the I-D that Jeff and I have worked on does not override, supersede, or obsolete RFC 2818 or any other prior art about matching rules for application server identity. Instead, we are attempting to abstract from that prior art to formulate forward-looking rules that capture the best aspects of current practice in a form that future application protocols can reference. If someday folks in the HTTP community wish to update or obsolete RFC 2818 by referencing this I-D, they will be free to do so -- but that is not the purpose of the work that Jeff and I have done. Peter -- Peter Saint-Andre https://stpeter.im/ From mrex@sap.com Mon Oct 11 13:31:31 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 633D83A6B86 for ; Mon, 11 Oct 2010 13:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.882 X-Spam-Level: X-Spam-Status: No, score=-9.882 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 EfLo1+OUIOb8 for ; Mon, 11 Oct 2010 13:31:28 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 35BA23A6B80 for ; Mon, 11 Oct 2010 13:31:28 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o9BKWdv2020198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Oct 2010 22:32:39 +0200 (MEST) From: Martin Rex Message-Id: <201010112031.o9BKVQML008586@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Mon, 11 Oct 2010 22:31:26 +0200 (MEST) In-Reply-To: <4CB35AD1.1060808@stpeter.im> from "Peter Saint-Andre" at Oct 11, 10 12:43:29 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal03 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 20:31:31 -0000 Peter Saint-Andre wrote: > > > > > I did issue server certs for wildcard substring matching when I > > implemented rfc-2818, though -- and I consider it likely that other > > implementors did this as well. > > That's nice, but not directly relevant to the current discussion because > the I-D that Jeff and I have worked on does not override, supersede, or > obsolete RFC 2818 or any other prior art about matching rules for > application server identity. I strongly disagree. the -09 wording: The client MUST fail to match a presented identifier in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net) attempts to invalidate rfc-2818 through the use of "MUST NOT". http://www.ietf.org/mail-archive/web/certid/current/msg00458.html -Martin From stpeter@stpeter.im Mon Oct 11 14:15:40 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C3C3A6B90 for ; Mon, 11 Oct 2010 14:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 T1kFu3nYWLvN for ; Mon, 11 Oct 2010 14:15:31 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 71AAA3A6B96 for ; Mon, 11 Oct 2010 14:15:21 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7D15B40BB9; Mon, 11 Oct 2010 15:23:11 -0600 (MDT) Message-ID: <4CB37EB0.9020602@stpeter.im> Date: Mon, 11 Oct 2010 15:16:32 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mrex@sap.com References: <201010112031.o9BKVQML008586@fs4113.wdf.sap.corp> In-Reply-To: <201010112031.o9BKVQML008586@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Oct 2010 21:15:40 -0000 On 10/11/10 2:31 PM, Martin Rex wrote: > Peter Saint-Andre wrote: >> >>> >>> I did issue server certs for wildcard substring matching when I >>> implemented rfc-2818, though -- and I consider it likely that other >>> implementors did this as well. >> >> That's nice, but not directly relevant to the current discussion because >> the I-D that Jeff and I have worked on does not override, supersede, or >> obsolete RFC 2818 or any other prior art about matching rules for >> application server identity. > > I strongly disagree. the -09 wording: > > The client MUST fail to match a presented identifier > in which the wildcard character is contained within a label fragment > (e.g., baz*.example.net is not allowed and MUST NOT be taken to match > baz1.example.net and baz2.example.net) > > attempts to invalidate rfc-2818 through the use of "MUST NOT". The next version (-10) will make it abundantly clear that this I-D does not (and does not intend to) override, supersede, update, or obsolete the rules for verifying server identity provided in specifications for existing application protocols. On this point, Jeff and I have added an applicability statement to our working copy, which we hope to release in the next day or two once we've checked it against all the issues that were raised during IETF Last Call. Peter -- Peter Saint-Andre https://stpeter.im/ From jorton@redhat.com Tue Oct 12 02:59:35 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384453A67E9 for ; Tue, 12 Oct 2010 02:59:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAs5Thb60pww for ; Tue, 12 Oct 2010 02:59:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 14F233A6803 for ; Tue, 12 Oct 2010 02:59:33 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o9CA0lm1007641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 12 Oct 2010 06:00:47 -0400 Received: from turnip.manyfish.co.uk (vpn-9-245.rdu.redhat.com [10.11.9.245]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o9CA0j1P017258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 12 Oct 2010 06:00:47 -0400 Received: from jorton by turnip.manyfish.co.uk with local (Exim 4.72) (envelope-from ) id 1P5bf3-0006yA-41 for certid@ietf.org; Tue, 12 Oct 2010 11:00:45 +0100 Date: Tue, 12 Oct 2010 11:00:45 +0100 From: Joe Orton To: certid@ietf.org Message-ID: <20101012100045.GA30760@redhat.com> Mail-Followup-To: certid@ietf.org References: <201010080200.o98208QR022569@fs4113.wdf.sap.corp> <4CB35AD1.1060808@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4CB35AD1.1060808@stpeter.im> User-Agent: Mutt/1.5.20 (2009-08-17) Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in UK and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 09:59:35 -0000 On Mon, Oct 11, 2010 at 12:43:29PM -0600, Peter Saint-Andre wrote: > Speaking of which, someone contacted Jeff and me off-list about some > research results showing that of a very large number of certificates > presented by TLS-protected websites, less than 0.01% contain wildcards > in component fragments. Given that minuscule level of deployment, I > don't see good reasons to spend more cycles on the topic. The relative number of certs is less relevant than how widely those certs are used, surely. I checked the "top 1m sites" database from: http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/ - 382860 total sites (hostnames) returned a cert - 94438 of total sites used a wildcard cert (24%) - 5% of total sites use the wildcard cert with CN=*.blogger.com ... other blogging/mass-hosting sites similarly high usage Only a handful (5) use the "f*.example.com" form; all those were certs issued by the GoDaddy and starfieldtech.com CAs. I support Martin's arguments that the "f*.example.com" form specified in RFC 2818 should be supported. Regards, Joe From matt@mattmccutchen.net Tue Oct 12 06:02:02 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E78D3A67D3 for ; Tue, 12 Oct 2010 06:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599] 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 ieLm6dnCgHjz for ; Tue, 12 Oct 2010 06:02:01 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by core3.amsl.com (Postfix) with ESMTP id 414973A67AE for ; Tue, 12 Oct 2010 06:02:01 -0700 (PDT) Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 88DD6280072; Tue, 12 Oct 2010 06:03:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=FFRfEOwhKBUJSMZgKoiYPOvboXrPSSiWgb0PJi0ct7Y b8mzpa5ria1Zr1zQNVxKIcJigQ9gbJbgOjDh4yktPQTdi2q2OsH/Ns0gNtq5KHXw bYCz8v5Mz7sUj8FdFgYtprsYFwMNYxv+Z0WSJOMZjfjmUzW04Ye5Q0ydTh20bw7w = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=ai9Cb+92XZBEtZZ2kZNElgS2I7s=; b=o4Ljw4RINM ZEjTEbnL6pIKHP4qAAHMS9BWs4aVI7/zwRsMVAnOfx7OFkUT3wegAOfYrD3M28S7 1lbYrKzMp2dpXdW/GzAAoxMqkk0K7yH7BY0mxN1eVliJwDZB+LzkraQHLv/GM2rp AMBHdlHkgT6X3kuXNUcsUnYUaYEI7bt0k= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPA id 43ACA28006D; Tue, 12 Oct 2010 06:03:15 -0700 (PDT) From: Matt McCutchen To: Peter Saint-Andre In-Reply-To: <4CB37EB0.9020602@stpeter.im> References: <201010112031.o9BKVQML008586@fs4113.wdf.sap.corp> <4CB37EB0.9020602@stpeter.im> Content-Type: text/plain; charset="UTF-8" Date: Tue, 12 Oct 2010 09:03:07 -0400 Message-ID: <1286888587.1922.11.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:02:02 -0000 On Mon, 2010-10-11 at 15:16 -0600, Peter Saint-Andre wrote: > On 10/11/10 2:31 PM, Martin Rex wrote: > > I strongly disagree. the -09 wording: > > > > The client MUST fail to match a presented identifier > > in which the wildcard character is contained within a label fragment > > (e.g., baz*.example.net is not allowed and MUST NOT be taken to match > > baz1.example.net and baz2.example.net) > > > > attempts to invalidate rfc-2818 through the use of "MUST NOT". > > The next version (-10) will make it abundantly clear that this I-D does > not (and does not intend to) override, supersede, update, or obsolete > the rules for verifying server identity provided in specifications for > existing application protocols. On this point, Jeff and I have added an > applicability statement to our working copy, which we hope to release in > the next day or two once we've checked it against all the issues that > were raised during IETF Last Call. This seems possibly disingenuous to me. The tls-server-id-check document may not itself update RFC 2818, but do you really intend that RFC 2818 never be updated in the future to use the tls-server-id-check rules? In view of the likelihood of such an update, it seems unhelpful to claim now that compatibility with RFC 2818 isn't our problem. -- Matt From stpeter@stpeter.im Tue Oct 12 06:04:03 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BA63A695A for ; Tue, 12 Oct 2010 06:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, 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 244p0Xlvsj0I for ; Tue, 12 Oct 2010 06:04:01 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id CF4203A67AE for ; Tue, 12 Oct 2010 06:04:01 -0700 (PDT) Received: from squire.local (dsl-140-58.dynamic-dsl.frii.net [216.17.140.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2B47E40337; Tue, 12 Oct 2010 07:11:57 -0600 (MDT) Message-ID: <4CB45D0A.40305@stpeter.im> Date: Tue, 12 Oct 2010 07:05:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matt McCutchen References: <201010112031.o9BKVQML008586@fs4113.wdf.sap.corp> <4CB37EB0.9020602@stpeter.im> <1286888587.1922.11.camel@mattlaptop2.local> In-Reply-To: <1286888587.1922.11.camel@mattlaptop2.local> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 13:04:03 -0000 On 10/12/10 7:03 AM, Matt McCutchen wrote: > On Mon, 2010-10-11 at 15:16 -0600, Peter Saint-Andre wrote: >> On 10/11/10 2:31 PM, Martin Rex wrote: >>> I strongly disagree. the -09 wording: >>> >>> The client MUST fail to match a presented identifier >>> in which the wildcard character is contained within a label fragment >>> (e.g., baz*.example.net is not allowed and MUST NOT be taken to match >>> baz1.example.net and baz2.example.net) >>> >>> attempts to invalidate rfc-2818 through the use of "MUST NOT". >> >> The next version (-10) will make it abundantly clear that this I-D does >> not (and does not intend to) override, supersede, update, or obsolete >> the rules for verifying server identity provided in specifications for >> existing application protocols. On this point, Jeff and I have added an >> applicability statement to our working copy, which we hope to release in >> the next day or two once we've checked it against all the issues that >> were raised during IETF Last Call. > > This seems possibly disingenuous to me. The tls-server-id-check > document may not itself update RFC 2818, but do you really intend that > RFC 2818 never be updated in the future to use the tls-server-id-check > rules? In view of the likelihood of such an update, it seems unhelpful > to claim now that compatibility with RFC 2818 isn't our problem. Shall I quote the text in our working copy? ### 1.3. Applicability and Audience This document does not supersede the rules for certificate issuance or validation provided in [PKIX], which governs any certificate- related topic on which this document is silent (e.g., certificate syntax, certificate extensions such as name constraints and extended key usage, and handling of certification paths). Specifically, in order to ensure proper authentication, application clients need to verify the entire certification path, because this document addresses only name forms in the leaf server certificate, not any name forms in the chain of certificates used to validate the server certificate. This document also does not supersede the rules for verifying service identity provided in specifications for existing application protocols, such as those mentioned under Appendix A. However, it is the intent of the authors that the best current practices described here can be referenced by future specifications, including updates to specifications for the aforementioned existing application protocols as collected under Appendix A, if the relevant technology communities agree to do so. It is also expected that this document will be updated or obsoleted in the future as best practices for issuance and verification of PKIX certificates continue to evolve through more widespread implementation and deployment of TLS-protected application services over the Internet. The primary audience for this document consists of application protocol designers, who might reference this document instead of defining their own rules for the representation and verification of application service identity. Secondarily, the audience consists of certification authorities, client developers, service providers, and other members of technology communities that might re-use or "profile" the recommendations in this document when defining certificate issuance policies, writing software algorithms for identity matching, generating certificate signing requests, etc. ### From jwkckid1@ix.netcom.com Tue Oct 12 12:28:47 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8073A69E9 for ; Tue, 12 Oct 2010 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.702 X-Spam-Level: X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=0.897, BAYES_00=-2.599] 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 o7lAsdRJstOW for ; Tue, 12 Oct 2010 12:28:46 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by core3.amsl.com (Postfix) with ESMTP id D71E83A6A4F for ; Tue, 12 Oct 2010 12:28:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=nYuABfuEElaoJMciXUaF+eJPPU0E7z8LgwDqwFQJ1LbMpD8uIkFUhHN/kKfp1S7q; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P5kXw-0000qU-El for certid@ietf.org; Tue, 12 Oct 2010 15:30:00 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 12 Oct 2010 15:30:00 -0400 Message-ID: <15609755.1286911800356.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Tue, 12 Oct 2010 14:30:00 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: certid@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688145120d3ad1e44ed14b153846b1ed016350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:28:47 -0000 Joe and all, I concur. -----Original Message----- >From: Joe Orton >Sent: Oct 12, 2010 5:00 AM >To: certid@ietf.org >Subject: Re: [certid] open issue: wildcards in component fragments > >On Mon, Oct 11, 2010 at 12:43:29PM -0600, Peter Saint-Andre wrote: >> Speaking of which, someone contacted Jeff and me off-list about some >> research results showing that of a very large number of certificates >> presented by TLS-protected websites, less than 0.01% contain wildcards >> in component fragments. Given that minuscule level of deployment, I >> don't see good reasons to spend more cycles on the topic. > >The relative number of certs is less relevant than how widely those >certs are used, surely. I checked the "top 1m sites" database from: > >http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/ > >- 382860 total sites (hostnames) returned a cert >- 94438 of total sites used a wildcard cert (24%) >- 5% of total sites use the wildcard cert with CN=*.blogger.com > ... other blogging/mass-hosting sites similarly high usage > >Only a handful (5) use the "f*.example.com" form; all those were certs >issued by the GoDaddy and starfieldtech.com CAs. > >I support Martin's arguments that the "f*.example.com" form specified in >RFC 2818 should be supported. > >Regards, Joe >_______________________________________________ >certid mailing list >certid@ietf.org >https://www.ietf.org/mailman/listinfo/certid Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From stpeter@stpeter.im Tue Oct 12 12:55:32 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 771E53A6A62 for ; Tue, 12 Oct 2010 12:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 9aZZQZ2Pxpi5 for ; Tue, 12 Oct 2010 12:55:31 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4399C3A6A5B for ; Tue, 12 Oct 2010 12:55:31 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2FD5040337 for ; Tue, 12 Oct 2010 14:03:29 -0600 (MDT) Message-ID: <4CB4BD7C.4000600@stpeter.im> Date: Tue, 12 Oct 2010 13:56:44 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: certid@ietf.org References: <201010080200.o98208QR022569@fs4113.wdf.sap.corp> <4CB35AD1.1060808@stpeter.im> <20101012100045.GA30760@redhat.com> In-Reply-To: <20101012100045.GA30760@redhat.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 19:55:33 -0000 On 10/12/10 4:00 AM, Joe Orton wrote: > On Mon, Oct 11, 2010 at 12:43:29PM -0600, Peter Saint-Andre wrote: >> Speaking of which, someone contacted Jeff and me off-list about some >> research results showing that of a very large number of certificates >> presented by TLS-protected websites, less than 0.01% contain wildcards >> in component fragments. Given that minuscule level of deployment, I >> don't see good reasons to spend more cycles on the topic. > > The relative number of certs is less relevant than how widely those > certs are used, surely. I checked the "top 1m sites" database from: > > http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/ > > - 382860 total sites (hostnames) returned a cert > - 94438 of total sites used a wildcard cert (24%) > - 5% of total sites use the wildcard cert with CN=*.blogger.com > ... other blogging/mass-hosting sites similarly high usage > > Only a handful (5) use the "f*.example.com" form; all those were certs > issued by the GoDaddy and starfieldtech.com CAs. You claim that the number of certs is less relevant than how widely those certs are used. So, how widely used are the 5 (!) out of 382860 certificates that contain wildcard component fragments? The fact that those certificates were issued by GoDaddy and Starfield Technologies means nothing. > I support Martin's arguments that the "f*.example.com" form specified in > RFC 2818 should be supported. What do you mean by "should be supported"? I see several claims that one could make: 1. Existing software whose matching algorithms support wildcard component fragments should stay as-is. 1a. Any new software written to perform identity matching should also contain matching algorithms that support wildcard component fragment. 2. Existing application protocols (see Appendix A of this I-D) that allow wildcard component fragments should not be changed. 2a. Any new application protocols developed by the IETF (or other SDOs) should also allow wildcard component fragments. 3. Wildcard component fragments are a best current practice for both certificate issuance and certificate validation, and therefore any BCP produced by the IETF at this time should recommend that all application protocols should support wildcard component fragments (thus putting at least RFC 5922 out of compliance, since that spec doesn't even allow complete wildcard components). I support #1 (with the proviso that it's an implementation decision for the relevant software developers whether they want to simplify their matching algorithms, based on a cost-benefit analysis of code complexity vs. a degraded user experience for less than 0.01% of issued certificates). I think #1a depends on which application protocol the software is designed to use (e.g., HTTP vs. SIP) -- conform to the spec you're implementing. I think #2 is just fine (with the proviso that such application protocols might decide to update their specs in the future based on experience and discussion within the relevant technology community). I disagree with #2a because I think that wildcard component fragments are not a *best* current practice, and I disagree with #3 for the same reason. What are the positions of those who are arguing for supporting wildcard component fragments, and why? Peter -- Peter Saint-Andre https://stpeter.im/ From mrex@sap.com Tue Oct 12 16:37:59 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 346083A6B39 for ; Tue, 12 Oct 2010 16:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.885 X-Spam-Level: X-Spam-Status: No, score=-9.885 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 a0IJzCL7nkXF for ; Tue, 12 Oct 2010 16:35:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id F17103A6B3A for ; Tue, 12 Oct 2010 16:33:15 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o9CNYMnm009478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Oct 2010 01:34:22 +0200 (MEST) From: Martin Rex Message-Id: <201010122334.o9CNYLVL008766@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Wed, 13 Oct 2010 01:34:21 +0200 (MEST) In-Reply-To: <4CB4BD7C.4000600@stpeter.im> from "Peter Saint-Andre" at Oct 12, 10 01:56:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 23:37:59 -0000 Peter Saint-Andre wrote: > > > http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/ > > > > - 382860 total sites (hostnames) returned a cert > > - 94438 of total sites used a wildcard cert (24%) > > - 5% of total sites use the wildcard cert with CN=*.blogger.com > > ... other blogging/mass-hosting sites similarly high usage > > > > Only a handful (5) use the "f*.example.com" form; all those were certs > > issued by the GoDaddy and starfieldtech.com CAs. > > You claim that the number of certs is less relevant than how widely > those certs are used. So, how widely used are the 5 (!) out of 382860 > certificates that contain wildcard component fragments? The fact that > those certificates were issued by GoDaddy and Starfield Technologies > means nothing. Very few commercial(!!) CAs (currently) issue wildcard certs at all. And of those commercial CAs that offer wildcard certs, only a fraction offers substring wildcard certs. Just because commercial CAs don't do it, doesn't mean that a DNS admin running his own CA would not want to do it either. > > > I support Martin's arguments that the "f*.example.com" form specified in > > RFC 2818 should be supported. > > What do you mean by "should be supported"? That this paragraph: The client MUST fail to match a presented identifier in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net) should be changed. Out of curiosity I just check the behaviour of the following browsers: MSIE7 on XPsp3 MSIE7 on W2K3sp2 MSIE8 on Win7 Firefox 3.0.17 (XPsp2) Firefox 3.5.9 (W2K3sp2) and they all appear show the exact *SAME* behaviour with respect to the following characteristics: wildcard in leftmost DNS label only: - YES: wildcard matching for "*.bar.example.com" - NO: wildcard matching for "foo.*.example.com" wildcard substring match: - YES: wildcard matching for "fo*.bar.example.com" - NO: other patterns "*oo.bar.example.com", "f*o.bar.example.com" For comparison, I also tried Opera 8.54 (the only one I have lying around), and it supports wildcards in multiple DNS labels as well as in arbitrary positions of the label, such as "f*o.ba*.example.com", "*oo.bar.example.com" While Opera 8.54 is within the scope of rfc-2818, I'm personally more comfortable of the behaviour exhibited by MSIE/SChannel and Firefox 3.x. > > I support #1 (with the proviso that it's an implementation decision for > the relevant software developers whether they want to simplify their > matching algorithms, based on a cost-benefit analysis of code complexity > vs. a degraded user experience for less than 0.01% of issued > certificates). I would not have the slighest problem if server-id-check said that Clients MAY ignore hostname identifiers in certificates that contain a wildcard character in other than the leftmost DNS label, and clients MAY ignore hostname identifiers where the leftmost DNS label contains characters in addition to the wildcard character, which would require partial string matches. Several web browsers have chosen a conservative approach to rfc-2818 wildcard substring match and support a partial wildcard only when the wildcard character appears at the end of the leftmost label, e.g. ""foo*.bar.example.com". > > What are the positions of those who are arguing for supporting wildcard > component fragments, and why? I consider the conservative approach of MSIE/SChannel and Firefox to allow a tail wildcard on the leftmost DNS label, in addition to a full wildcard, sensitive risk management combined with minimal complexity. -Martin From matt@mattmccutchen.net Tue Oct 12 16:50:42 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D59DD3A6856 for ; Tue, 12 Oct 2010 16:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599] 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 6ztWF3pk1CUC for ; Tue, 12 Oct 2010 16:50:40 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id A5FEB3A6860 for ; Tue, 12 Oct 2010 16:50:40 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id D402910AFAD; Tue, 12 Oct 2010 16:51:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=s9xY4fZbkNpgW/Mtct29n8bf+1sqpki2XeDYa1uhOjp VQ6keEmG8lBJO3dYOxaRp35aIHL4LHAf4044y0cHRMsP/rWoK4R49YVPPs4j3r+7 HWLBEk+XE358Cl1pjN3EAV5eDt5W8IhoQ7oNicUW3jc4HhSQpSm329iHII4fmmL8 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=3atTfC7zudcX/9GuJzTspoXnSqI=; b=FFZOZs2h6j PSQiocAs3sRAfrCPdVbqAO0X0MRI3Z8TS0lat0DPhG0Dq9puW/UF7niLtHBgRVnn FY5Rz88WFW2SsHqiXNoJx7ycjoDlhbpFqeL2igxSF16godcE42KQy1QTW8j9UtiB jOUuVq19ytNVkv9bc7Z4PCwnvI7IrOv28= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPA id 6085F10AFA5; Tue, 12 Oct 2010 16:51:55 -0700 (PDT) From: Matt McCutchen To: mrex@sap.com In-Reply-To: <201010122334.o9CNYLVL008766@fs4113.wdf.sap.corp> References: <201010122334.o9CNYLVL008766@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Tue, 12 Oct 2010 19:51:54 -0400 Message-ID: <1286927514.1979.13.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 23:50:43 -0000 On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote: > I consider the conservative approach of MSIE/SChannel and Firefox to > allow a tail wildcard on the leftmost DNS label, in addition to a > full wildcard, sensitive risk management combined with minimal complexity. As I said before, I don't think this "risk management" argument is real. CAs are responsible for not giving an entity a certificate that matches names the entity does not own. Why should we believe they are any more likely to mess up via wildcards than, e.g., by setting the basic constraint "CA: true"? -- Matt From stpeter@stpeter.im Tue Oct 12 17:33:42 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F713A686E for ; Tue, 12 Oct 2010 17:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, 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 IsnpqO1UC+vl for ; Tue, 12 Oct 2010 17:33:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id A908C3A6832 for ; Tue, 12 Oct 2010 17:33:40 -0700 (PDT) Received: from squire.local (dsl-140-58.dynamic-dsl.frii.net [216.17.140.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2DFFE40077; Tue, 12 Oct 2010 18:41:40 -0600 (MDT) Message-ID: <4CB4FEAE.3090700@stpeter.im> Date: Tue, 12 Oct 2010 18:34:54 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matt McCutchen References: <201010122334.o9CNYLVL008766@fs4113.wdf.sap.corp> <1286927514.1979.13.camel@mattlaptop2.local> In-Reply-To: <1286927514.1979.13.camel@mattlaptop2.local> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 00:33:42 -0000 On 10/12/10 5:51 PM, Matt McCutchen wrote: > On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote: >> I consider the conservative approach of MSIE/SChannel and Firefox to >> allow a tail wildcard on the leftmost DNS label, in addition to a >> full wildcard, sensitive risk management combined with minimal complexity. > > As I said before, I don't think this "risk management" argument is real. > CAs are responsible for not giving an entity a certificate that matches > names the entity does not own. Why should we believe they are any more > likely to mess up via wildcards than, e.g., by setting the basic > constraint "CA: true"? Matt, what conclusion do you draw from your statement? IMHO it might lead to the conclusion that it doesn't matter what we put in the left-most label -- or even the conclusion that we don't need to restrict the location of the wildcard (e.g., foo.*.example.com or even *.*.example.com is fine) -- as long as the CA issues a certificate that matches a name the entity owns. Peter -- Peter Saint-Andre https://stpeter.im/ From matt@mattmccutchen.net Tue Oct 12 18:08:56 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C87BA3A6832 for ; Tue, 12 Oct 2010 18:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599] 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 T1Ueqq2eQZDA for ; Tue, 12 Oct 2010 18:08:55 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by core3.amsl.com (Postfix) with ESMTP id B068B3A689A for ; Tue, 12 Oct 2010 18:08:55 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 18AF251C069; Tue, 12 Oct 2010 18:10:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=dokFtAxD1Awp7VC+yZPjHjj/O+B95w4HRPlKeasLgAq qRN7v9wx78nXI6vpCzUj78reaKoQkjXLcIYFIXOeHG1spCNZSk3+DsVI/z+WgbM2 lXymC0VaSAkExlCcBYuLJI3e+9yjfVOMpB24ow8ppvsDZEMrG3/ItanThRABPOj4 = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=7ymW1+J5mTdtIK3M0w1BecAjtr8=; b=nt5+6Sop0j D5+dVSzvJc+nuUEzLmTsf7Odyit/o5HoNp8XJQcAOuYrsaQ5ZGM0ESDpeJ7iQvOo wkXBNJqAmRokrPOOXBEoivT6UFT7l6lEY7WhGv3DZhxmneObM3XxfBS3+5R/cjDS wCbWXjWBy0UM38VSk/FrYZiJZbHkv3tT4= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id B0D7251C063; Tue, 12 Oct 2010 18:10:10 -0700 (PDT) From: Matt McCutchen To: Peter Saint-Andre In-Reply-To: <4CB4FEAE.3090700@stpeter.im> References: <201010122334.o9CNYLVL008766@fs4113.wdf.sap.corp> <1286927514.1979.13.camel@mattlaptop2.local> <4CB4FEAE.3090700@stpeter.im> Content-Type: text/plain; charset="UTF-8" Date: Tue, 12 Oct 2010 21:10:09 -0400 Message-ID: <1286932209.1979.22.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 01:08:56 -0000 On Tue, 2010-10-12 at 18:34 -0600, Peter Saint-Andre wrote: > On 10/12/10 5:51 PM, Matt McCutchen wrote: > > On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote: > >> I consider the conservative approach of MSIE/SChannel and Firefox to > >> allow a tail wildcard on the leftmost DNS label, in addition to a > >> full wildcard, sensitive risk management combined with minimal complexity. > > > > As I said before, I don't think this "risk management" argument is real. > > CAs are responsible for not giving an entity a certificate that matches > > names the entity does not own. Why should we believe they are any more > > likely to mess up via wildcards than, e.g., by setting the basic > > constraint "CA: true"? > > Matt, what conclusion do you draw from your statement? IMHO it might > lead to the conclusion that it doesn't matter what we put in the > left-most label -- or even the conclusion that we don't need to restrict > the location of the wildcard (e.g., foo.*.example.com or even > *.*.example.com is fine) -- as long as the CA issues a certificate that > matches a name the entity owns. That's right from the perspective of "risk management". All I wanted to do was put that argument aside. There are other arguments to consider, e.g., "simpler" algorithms are easier to implement and more likely to be implemented correctly, and compatibility with specifications that might want to update to reference tls-server-id-check. -- Matt From stpeter@stpeter.im Tue Oct 12 18:32:32 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4EA93A689A for ; Tue, 12 Oct 2010 18:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, 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 ePebRRr+QQZK for ; Tue, 12 Oct 2010 18:32:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9A3BB3A686A for ; Tue, 12 Oct 2010 18:32:27 -0700 (PDT) Received: from squire.local (dsl-140-58.dynamic-dsl.frii.net [216.17.140.58]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5716540077; Tue, 12 Oct 2010 19:40:27 -0600 (MDT) Message-ID: <4CB50C74.8020507@stpeter.im> Date: Tue, 12 Oct 2010 19:33:40 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Matt McCutchen References: <201010122334.o9CNYLVL008766@fs4113.wdf.sap.corp> <1286927514.1979.13.camel@mattlaptop2.local> <4CB4FEAE.3090700@stpeter.im> <1286932209.1979.22.camel@mattlaptop2.local> In-Reply-To: <1286932209.1979.22.camel@mattlaptop2.local> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 01:32:33 -0000 On 10/12/10 7:10 PM, Matt McCutchen wrote: > On Tue, 2010-10-12 at 18:34 -0600, Peter Saint-Andre wrote: >> On 10/12/10 5:51 PM, Matt McCutchen wrote: >>> On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote: >>>> I consider the conservative approach of MSIE/SChannel and Firefox to >>>> allow a tail wildcard on the leftmost DNS label, in addition to a >>>> full wildcard, sensitive risk management combined with minimal complexity. >>> >>> As I said before, I don't think this "risk management" argument is real. >>> CAs are responsible for not giving an entity a certificate that matches >>> names the entity does not own. Why should we believe they are any more >>> likely to mess up via wildcards than, e.g., by setting the basic >>> constraint "CA: true"? >> >> Matt, what conclusion do you draw from your statement? IMHO it might >> lead to the conclusion that it doesn't matter what we put in the >> left-most label -- or even the conclusion that we don't need to restrict >> the location of the wildcard (e.g., foo.*.example.com or even >> *.*.example.com is fine) -- as long as the CA issues a certificate that >> matches a name the entity owns. > > That's right from the perspective of "risk management". All I wanted to > do was put that argument aside. I see, and I agree. > There are other arguments to consider, > e.g., "simpler" algorithms are easier to implement and more likely to be > implemented correctly, That seems to be the operative consideration. Martin claimed that it is a "conservative approach ... to allow a tail wildcard on the leftmost DNS label" but RFC 2818 doesn't say anything about a "tail wildcard" (e.g., foo*): Names may contain the wildcard character * which is considered to match any single domain name component or component fragment. E.g., *.a.com matches foo.a.com but not bar.foo.a.com. f*.com matches foo.com but not bar.com. Yes, the example here shows a tail wildcard, but as far as I can see the rule of allowing the wildcard character in a component fragment does not restrict '*' to the tail -- it could just as well be a "front wildcard" (e.g., *oo) or a "middle wildcard" (e.g., f*o). All of these increase the complexity of the matching algorithm, for very little if any gain that I can see. > and compatibility with specifications that might > want to update to reference tls-server-id-check. Well, that's not a legitimate argument because it begs the question. :) Peter -- Peter Saint-Andre https://stpeter.im/ From mrex@sap.com Tue Oct 12 21:49:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB5F3A67AF for ; Tue, 12 Oct 2010 21:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.889 X-Spam-Level: X-Spam-Status: No, score=-9.889 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 iYAqDfWgr0x8 for ; Tue, 12 Oct 2010 21:49:36 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 203E93A6B37 for ; Tue, 12 Oct 2010 21:49:35 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o9D4onmN029692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Oct 2010 06:50:49 +0200 (MEST) From: Martin Rex Message-Id: <201010130450.o9D4omeE024689@fs4113.wdf.sap.corp> To: matt@mattmccutchen.net (Matt McCutchen) Date: Wed, 13 Oct 2010 06:50:48 +0200 (MEST) In-Reply-To: <1286927514.1979.13.camel@mattlaptop2.local> from "Matt McCutchen" at Oct 12, 10 07:51:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 04:49:40 -0000 Matt McCutchen wrote: > > On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote: > > I consider the conservative approach of MSIE/SChannel and Firefox to > > allow a tail wildcard on the leftmost DNS label, in addition to a > > full wildcard, sensitive risk management combined with minimal complexity. > > As I said before, I don't think this "risk management" argument is real. The rist management argument is VERY real. Recall the numbers: : : http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/ : : - 382860 total sites (hostnames) returned a cert : - 94438 of total sites used a wildcard cert (24%) : - 5% of total sites use the wildcard cert with CN=*.blogger.com : ... other blogging/mass-hosting sites similarly high usage : : Only a handful (5) use the "f*.example.com" form; all those were certs : issued by the GoDaddy and starfieldtech.com CAs. Full wildcard certs are dangerous, because they will match any host in a domain (which makes them a much more interesting target for credential-stealing). I assume that a non-negligible of those servers that are currently using full wildcards could be using tail-match wildcards instead -- something which could reduce the risk for some of the other servers in a domain. The reason why tail-wildcards are rarely used is probably not that server operators do not like them or browsers would not support them, but that there are currently not enough CAs offering them. Now instead of killing something which would help the risk managment of server operaters, server-id-check should describe tail-wildcards on the leftmost DNS label as an alternative to full wildcards as a MAY. -Martin From stpeter@stpeter.im Wed Oct 13 10:44:14 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C27AD3A6969 for ; Wed, 13 Oct 2010 10:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, 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 B7b75fYfyvur for ; Wed, 13 Oct 2010 10:44:13 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 60C2B3A692F for ; Wed, 13 Oct 2010 10:44:13 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9C31040337; Wed, 13 Oct 2010 11:52:17 -0600 (MDT) Message-ID: <4CB5F037.5050103@stpeter.im> Date: Wed, 13 Oct 2010 11:45:27 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mrex@sap.com References: <201010130450.o9D4omeE024689@fs4113.wdf.sap.corp> In-Reply-To: <201010130450.o9D4omeE024689@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 17:44:14 -0000 On 10/12/10 10:50 PM, Martin Rex wrote: > Matt McCutchen wrote: >> >> On Wed, 2010-10-13 at 01:34 +0200, Martin Rex wrote: >>> I consider the conservative approach of MSIE/SChannel and Firefox to >>> allow a tail wildcard on the leftmost DNS label, in addition to a >>> full wildcard, sensitive risk management combined with minimal complexity. >> >> As I said before, I don't think this "risk management" argument is real. > > The rist management argument is VERY real. > > Recall the numbers: > : > : http://blog.johnath.com/2009/01/21/ssl-information-wants-to-be-free/ > : > : - 382860 total sites (hostnames) returned a cert > : - 94438 of total sites used a wildcard cert (24%) > : - 5% of total sites use the wildcard cert with CN=*.blogger.com > : ... other blogging/mass-hosting sites similarly high usage > : > : Only a handful (5) use the "f*.example.com" form; all those were certs > : issued by the GoDaddy and starfieldtech.com CAs. > > > Full wildcard certs are dangerous, because they will match any host > in a domain (which makes them a much more interesting target for > credential-stealing). How so? If I can steal credentials such that I have access to verifying addresses for example.com, then I can convince a CA to issue whatever certificates I want. If the "example.com" property is valuable then the differences between example.com, *.example.com, and foo* or *oo or f*o.example.com are negligible. I really doubt that any thief is going to be significantly more attracted to stealing credentials because he knows that he can go to a CA and get *.example.com instead of "merely" foo*.example.com and www*.example.com and so on. And if that were the case then it would simply be a matter of CA-shopping (which the bad guys already do). > I assume that a non-negligible of those servers that are currently using > full wildcards could be using tail-match wildcards instead -- something > which could reduce the risk for some of the other servers in a domain. If folks were really interested in risk mitigation then presumably they'd be using things like SRV-IDs (limits the damage to a particular service type), EKU, name constraints, locking down canonical email addresses, etc., or at least not using wildcard certs in any way and requesting only certificates for named application services (e.g., mail.example.com instead of m*.example.com or *.example.com). Character matching on www* seems a lot less valuable than many other measures an organization could take. Furthermore, there is no way for an application service provider to signal to application clients that they should not accept wildcard certificates, so the primary benefits here accrue to the provider -- in which case they can simply define their own organizational policies and procedures for certificate requests, and perhaps communicate those to their favorite CAs. Finally, figuring out which measures are most effective at mitigating risk would require a breadth of research (analysis of various attacks etc.) that is beyond the scope of this I-D. > The reason why tail-wildcards are rarely used is probably not that server > operators do not like them We have no way of knowing whether application service providers like them or not, absent surveys of some kind. > or browsers would not support them, > but that there are currently not enough CAs offering them. > > Now instead of killing something which would help the risk managment > of server operaters, server-id-check should describe tail-wildcards > on the leftmost DNS label as an alternative to full wildcards as a MAY. The logical conclusion from your line of reasoning is to forbid all wildcard certificates, whether full-label, tail, head, torso, or anything else, but you don't seem to want to go that far. Why not? And why are tail wildcards so much safer than head or torso wildcards? Note that at least two technology communities have forbidden wildcard certificates: 1. RFC 5992 forbids wildcard certificates in the SIP community. 2. The CA/Browser Forum doesn't allow issuance of wildcard certificates under its "Extended Valuation Certificates" profile. So there is some precedent for forbidding wildcard certificates. Is that a best current practice? Should this I-D state that wildcard certificates (of whatever variety) are NOT RECOMMENDED? Peter -- Peter Saint-Andre https://stpeter.im/ From Jeff.Hodges@KingsMountain.com Wed Oct 13 14:38:26 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547F23A66B4 for ; Wed, 13 Oct 2010 14:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.137 X-Spam-Level: X-Spam-Status: No, score=-102.137 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 WZ07UKgMo98H for ; Wed, 13 Oct 2010 14:38:24 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 1BB443A69DF for ; Wed, 13 Oct 2010 14:38:24 -0700 (PDT) Received: (qmail 28909 invoked by uid 0); 13 Oct 2010 21:39:41 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 13 Oct 2010 21:39:41 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=FyttNTWYa/l6C2qqWMXo5WcM5NocJ1IORn3HQobYtSbQhBeyrekZdUXvdKTj7I9ER6NZlPNuwMKWkS2QGyZsOEKdDQREdPmLNJgwdHFx7/FfesCgSOagFCoEG9W5urCn; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P692y-0003hi-SM for certid@ietf.org; Wed, 13 Oct 2010 15:39:41 -0600 Message-ID: <4CB6271A.7090402@KingsMountain.com> Date: Wed, 13 Oct 2010 14:39:38 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 21:38:26 -0000 > Note that at least two technology communities have forbidden wildcard > certificates: > > 1. RFC 5992 forbids wildcard certificates in the SIP community. > > 2. The CA/Browser Forum doesn't allow issuance of wildcard certificates > under its "Extended Valuation Certificates" profile. > > So there is some precedent for forbidding wildcard certificates. Is that > a best current practice? Should this I-D state that wildcard > certificates (of whatever variety) are NOT RECOMMENDED? I'm thinking that the latter is the way to go wrt wildcards. RFC2119 sez.. 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. ..which certainly sounds reasonable for this situation. Our working copy of -tls-server-id-check (which are trying to pub by end of this week) has further clarifications wrt the spec's not outright forbidding current practice and various other current specifications, thus present wildcard use does not necessarily conflict with such a "NOT RECOMMENDED" stance. Plus such a stance aligns better with the EV Guidelines, RFC5992, and perhaps other specs going forward. =JeffH From stpeter@stpeter.im Wed Oct 13 14:51:20 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6242D3A66B4 for ; Wed, 13 Oct 2010 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 TKUv86JVXzQx for ; Wed, 13 Oct 2010 14:51:07 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 40F0A3A6A65 for ; Wed, 13 Oct 2010 14:51:05 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C307940337 for ; Wed, 13 Oct 2010 15:59:11 -0600 (MDT) Message-ID: <4CB62A13.30401@stpeter.im> Date: Wed, 13 Oct 2010 15:52:19 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: certid@ietf.org References: <4CB6271A.7090402@KingsMountain.com> In-Reply-To: <4CB6271A.7090402@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 21:51:20 -0000 On 10/13/10 3:39 PM, =JeffH wrote: >> Note that at least two technology communities have forbidden wildcard >> certificates: >> >> 1. RFC 5992 forbids wildcard certificates in the SIP community. >> >> 2. The CA/Browser Forum doesn't allow issuance of wildcard certificates >> under its "Extended Valuation Certificates" profile. >> >> So there is some precedent for forbidding wildcard certificates. Is that >> a best current practice? Should this I-D state that wildcard >> certificates (of whatever variety) are NOT RECOMMENDED? > > > I'm thinking that the latter is the way to go wrt wildcards. RFC2119 sez.. > > 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label. > > ..which certainly sounds reasonable for this situation. > > Our working copy of -tls-server-id-check (which are trying to pub by end > of this week) has further clarifications wrt the spec's not outright > forbidding current practice and various other current specifications, > thus present wildcard use does not necessarily conflict with such a "NOT > RECOMMENDED" stance. Plus such a stance aligns better with the EV > Guidelines, RFC5992, and perhaps other specs going forward. Jeff and I have been thinking about this independently today, and it seems we're going in the same direction. Following Martin Rex's argument to its logical conclusion has led me to believe that wildcards deserve to be NOT RECOMMENDED in a best current practice document. Peter -- Peter Saint-Andre https://stpeter.im/ From jwkckid1@ix.netcom.com Wed Oct 13 14:54:07 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B623A69DF for ; Wed, 13 Oct 2010 14:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_00=-2.599] 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 kLxm8m2SNj+Y for ; Wed, 13 Oct 2010 14:54:05 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id BCA0A3A69CE for ; Wed, 13 Oct 2010 14:54:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=RB2G5p+6ecgIsMFqsS51ZXYR6ppM4RBzaa0NkG1loovYo21nqi7wHZvtSJM22sl1; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P69IB-0001Fj-3o; Wed, 13 Oct 2010 17:55:23 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 13 Oct 2010 17:55:22 -0400 Message-ID: <31141027.1287006922964.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> Date: Wed, 13 Oct 2010 16:55:22 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Peter Saint-Andre , certid@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b3a026eb20ec7ddbb827fe8c44f41e74350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.36 Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 21:54:07 -0000 Peter, Rex, and all, -----Original Message----- >From: Peter Saint-Andre >Sent: Oct 13, 2010 4:52 PM >To: certid@ietf.org >Subject: Re: [certid] open issue: wildcards in component fragments > >On 10/13/10 3:39 PM, =JeffH wrote: >>> Note that at least two technology communities have forbidden wildcard >>> certificates: >>> >>> 1. RFC 5992 forbids wildcard certificates in the SIP community. >>> >>> 2. The CA/Browser Forum doesn't allow issuance of wildcard certificates >>> under its "Extended Valuation Certificates" profile. >>> >>> So there is some precedent for forbidding wildcard certificates. Is that >>> a best current practice? Should this I-D state that wildcard >>> certificates (of whatever variety) are NOT RECOMMENDED? >> >> >> I'm thinking that the latter is the way to go wrt wildcards. RFC2119 sez.. >> >> 4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that >> there may exist valid reasons in particular circumstances when the >> particular behavior is acceptable or even useful, but the full >> implications should be understood and the case carefully weighed >> before implementing any behavior described with this label. >> >> ..which certainly sounds reasonable for this situation. >> >> Our working copy of -tls-server-id-check (which are trying to pub by end >> of this week) has further clarifications wrt the spec's not outright >> forbidding current practice and various other current specifications, >> thus present wildcard use does not necessarily conflict with such a "NOT >> RECOMMENDED" stance. Plus such a stance aligns better with the EV >> Guidelines, RFC5992, and perhaps other specs going forward. > >Jeff and I have been thinking about this independently today, and it >seems we're going in the same direction. Following Martin Rex's argument >to its logical conclusion has led me to believe that wildcards deserve >to be NOT RECOMMENDED in a best current practice document. I agree completely. > >Peter > >-- >Peter Saint-Andre >https://stpeter.im/ > > >_______________________________________________ >certid mailing list >certid@ietf.org >https://www.ietf.org/mailman/listinfo/certid Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From mrex@sap.com Wed Oct 13 15:19:19 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 446AF3A66B4 for ; Wed, 13 Oct 2010 15:19:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.892 X-Spam-Level: X-Spam-Status: No, score=-9.892 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 p1tcgo-cvFuW for ; Wed, 13 Oct 2010 15:19:18 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0E79E3A67E2 for ; Wed, 13 Oct 2010 15:19:17 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o9DMKTKP017941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2010 00:20:34 +0200 (MEST) From: Martin Rex Message-Id: <201010132220.o9DMKTjG024980@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Thu, 14 Oct 2010 00:20:29 +0200 (MEST) In-Reply-To: <4CB62A13.30401@stpeter.im> from "Peter Saint-Andre" at Oct 13, 10 03:52:19 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 22:19:19 -0000 Peter Saint-Andre wrote: > > Jeff and I have been thinking about this independently today, and it > seems we're going in the same direction. Following Martin Rex's argument > to its logical conclusion has led me to believe that wildcards deserve > to be NOT RECOMMENDED in a best current practice document. I'm certainly in favor of NOT RECOMMENDING the use of any wildcards to server admins (and to a lesser extent app protocol designers) in the security considerations section of the server-id-check document. I'm less inclined about recommending to implementations to not implement it at all (which is about utility functions of the TLS implementation for use by the application). Aside from pathological cases (like a DV-validated cert issued with DNS-ID="*", "*.*", "*.*.*" and extremely "liberal" TLS-client-implementations of rfc-2818), the risk about wildcard certs is more about the administrative procedures of the server & domain admins using such certs. Keep in mind that the security of all the servers in the domain vitally depend on responsible admins and reasonably safe procedures, and the matching rules described in server-id-check are hardly going to affect that. The other extreme, of server certificates that list several hundred DNS-IDs is not necessarily safer than a single wildcard. Rather than leaving the issue of wildcards as underspecified as rfc-2818, I would appreciate a few words of what is commonly available in current web browsers and could be implemented with minor effort and low complexity. -Martin From stpeter@stpeter.im Thu Oct 14 14:57:58 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9BB3A6BFE for ; Thu, 14 Oct 2010 14:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, 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 WqMc-Mu7-1LM for ; Thu, 14 Oct 2010 14:57:57 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E4E103A6A09 for ; Thu, 14 Oct 2010 14:57:56 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 89F6C40337; Thu, 14 Oct 2010 16:06:10 -0600 (MDT) Message-ID: <4CB77D32.1080406@stpeter.im> Date: Thu, 14 Oct 2010 15:59:14 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: mrex@sap.com References: <201010132220.o9DMKTjG024980@fs4113.wdf.sap.corp> In-Reply-To: <201010132220.o9DMKTjG024980@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090207070103030200090806" Cc: certid@ietf.org Subject: Re: [certid] open issue: wildcards in component fragments X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Oct 2010 21:57:58 -0000 This is a cryptographically signed message in MIME format. --------------ms090207070103030200090806 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/13/10 4:20 PM, Martin Rex wrote: > Peter Saint-Andre wrote: >> >> Jeff and I have been thinking about this independently today, and it >> seems we're going in the same direction. Following Martin Rex's argume= nt >> to its logical conclusion has led me to believe that wildcards deserve= >> to be NOT RECOMMENDED in a best current practice document. >=20 > I'm certainly in favor of NOT RECOMMENDING the use of any wildcards > to server admins (and to a lesser extent app protocol designers) > in the security considerations section of the server-id-check > document. >=20 > I'm less inclined about recommending to implementations to > not implement it at all (which is about utility functions of the > TLS implementation for use by the application). After further reflection, I agree with you. I think Jeff is on board with that, as well. We should be able to publish -10 real soon now. > Rather than leaving the issue of wildcards as underspecified as > rfc-2818, I would appreciate a few words of what is commonly > available in current web browsers and could be implemented with > minor effort and low complexity. Proposed text is always welcome. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms090207070103030200090806 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx NDIxNTkxNFowIwYJKoZIhvcNAQkEMRYEFJikhcIM2d4tfUytGQfsuyLXJOB2MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBXzbP0Lejdgk6wOcgoxwrWuYSvP32kyrYVLBOP2CtKh5ZE6zSH3Ri3lQu/ a/xWbDv9O9QYlcjWtdY/fRZjsAPkaiHw8sGBjjv8dRm0HRz2ndK9uWsJWbLjUNEkc4RWLReP WFjdqHlYSYgurx4GusrYyszsLExtp4CIVlFFEWJAHOyhz7bje/0YhlxCaD6yezKTHLwhrqn4 1HtDQ7T8s3PmAi0BjU3DhmuPqwNDoeVwt+Oo2mZqJhzz40T7C/HTqpZ2E2leb6OXI7H5X6Zc 0m/0d8o3kmvOrf9jo3ZlRvhCRtZG8df2n2/SDIpAGmHftN7zZS8j4VMW3KLctwgYqwvgAAAA AAAA --------------ms090207070103030200090806-- From Jeff.Hodges@KingsMountain.com Fri Oct 15 12:10:43 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9F9D3A6AFE for ; Fri, 15 Oct 2010 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.839 X-Spam-Level: X-Spam-Status: No, score=-100.839 tagged_above=-999 required=5 tests=[AWL=-1.174, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 yiEk2HlT9amx for ; Fri, 15 Oct 2010 12:10:38 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 7DE703A6981 for ; Fri, 15 Oct 2010 12:10:38 -0700 (PDT) Received: (qmail 3834 invoked by uid 0); 15 Oct 2010 19:12:00 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 15 Oct 2010 19:12:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=cOuZVCRUYFynFn3imJ23OeWqTaVIwgl7DCIJ2ExstJpLpLepnsAvJRNXbxGg3EviQN7dUG+irqGP3xd4Sw6GfPZx/X2jtUguNKQuAqGY18TKKH18E2UzEpgSPagYeVxg; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P6phA-0005Xn-2Z for certid@ietf.org; Fri, 15 Oct 2010 13:12:00 -0600 Message-ID: <4CB8A77E.90009@KingsMountain.com> Date: Fri, 15 Oct 2010 12:11:58 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [certid] fyi: Ivan Ristic / Qualsys SSL Labs release raw data from the Internet SSL survey X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 19:10:43 -0000 October 05, 2010 Qualys SSL Labs releases raw data from the Internet SSL survey About two months ago, Qualys SSL Labs published the results of an Interne= t-wide=20 SSL survey. We said that we would make the raw data available, and today = we are=20 following up on that promise. (By the way, we realize that two months is = a long=20 time, but we couldn't complete the process faster on this occasion. We ho= pe to=20 make future releases pretty much as soon as we obtain the data. As you ma= y=20 remember, our plan it to make our survey a quarterly event from 2011.) The raw data contains the SSL assessment results of about 850,000 domain = names=20 (out of about 120M we inspected). The main file (1.2 GB 120 MB compressed= , 3.5=20 GB 800 MB uncompressed) is a dump of our PostgreSQL database in CSV forma= t. We=20 include in the download a simple PHP script that iterates through all the= rows,=20 which means that you can consume the data directly. Alternatively, you ca= n put=20 the data back into the database and use SQL to run ad-hoc queries (we pro= vide=20 the schema along with the import instructions). The database schema contains 63 fields that generally parallel the inform= ation=20 you would obtain from the SSL Labs online test. The complete original=20 certificate chain is included, which is handy if you want to look into th= e=20 aspects we didn't. We chose not to release certain sensitive data: the=20 information on the low entropy private keys, renegotiation support, and H= TTP=20 server signatures was removed. This is what you need to do to obtain the data: 1. First, make sure that our terms and conditions are acceptable to y= ou. At=20 the core, we use the Creative Commons Attribution-NonCommercial-ShareAlik= e 3.0=20 Unported licence, but there are a few additional requirements. For exampl= e, we=20 ask the obvious -- that you don't use the data for illegal activities. Th= e=20 other requirements are just common sense. (Please do read the entire file= ,=20 however.) 2. Second, send us an email (username "ivanr"; domain name=20 "webkreator.com"), introduce yourself, and tell us how you intend to use= the=20 data. We will then send you back the download instructions. We need this = second=20 step to give us an idea if the data is used, and how. Update: We are removing the certificate chain data from the database unti= l we=20 confirm that we are legally allowed to redistribute it. If you need such = data=20 in the meantime, retrieve it directly from the servers. Posted by Ivan Risti=C4=87 at 12:29:04 in SSL From Jeff.Hodges@KingsMountain.com Fri Oct 15 14:00:35 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CAFE3A6BCC for ; Fri, 15 Oct 2010 14:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.192 X-Spam-Level: X-Spam-Status: No, score=-101.192 tagged_above=-999 required=5 tests=[AWL=-0.786, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, 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 Oj0PMY6IN5Jm for ; Fri, 15 Oct 2010 14:00:34 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 668DE3A6D28 for ; Fri, 15 Oct 2010 14:00:34 -0700 (PDT) Received: (qmail 20903 invoked by uid 0); 15 Oct 2010 21:01:56 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 15 Oct 2010 21:01:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=bEpMAewMPUv/gUs7fv6l/n5FZLh+pkl3FEzqyrDXzICsqlvFW6pc0wry5IG1At3+iAZb3TWVq7u4movCDBzUunJBS9pYPugHadQDSr4YqlVFGAKbxfcC9Zg/gvCHJTc9; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P6rPY-000624-2R for certid@ietf.org; Fri, 15 Oct 2010 15:01:56 -0600 Message-ID: <4CB8C142.4030003@KingsMountain.com> Date: Fri, 15 Oct 2010 14:01:54 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [certid] some info from SSL labs cert survey data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:00:35 -0000 I've done some modest poking around the SSL labs cert survey data, below's some numbers. First, the dataset has 867361 domains along with data extracted from their certs (one row per domain). The details on how Ivan selected the domains are here.. That explanation hints that most all the certs represented in the dataset would be "valid" certs. However, there's ~150k more entries in the dbase than the ~720K valid certs he observed. Though, there's ~150k apparently "self-signed" certs in the dbase, so perhaps that's what's filling out the dbase. Here's some quick numbers.. all 867361 have a "CN=" in the subject name (CN-ID). None appear to have more than one CN-ID 392497 (45%) use the subjectAltName field for at least one altName (of some type (I haven't yet investigated whether he gathered more than only DNS-IDs (but upon quick browsing it looks like they are most all DNS-IDs))) 6487 (0.75%) have > 5 altNames (of some type) 145 (0.02%) have > 50 altNames (of some type) 33831 (4%) use a wildcard in their name in some fashion (they sometimes are in CN-ID, or subjectAltName, or both it appears upon quick browsing) 153113 (18%) have a null trustAnchor field - suggesting they are self-signed(?) 99673 (11%) have subjectCommonName == issuerCommonName -- most self-signed(?) 52929 (6%) have subjectCommonName != issuerCommonName and a null trustAnchor field. 0 have subjectCommonName == issuerCommonName and a non-null trustAnchor field. There are 86 distinct trustAnchor names in the data set. HTH, =JeffH From stpeter@stpeter.im Fri Oct 15 14:15:02 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4893A6D34 for ; Fri, 15 Oct 2010 14:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, 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 xyUTYrtSx2ug for ; Fri, 15 Oct 2010 14:15:00 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0B63C3A6BCC for ; Fri, 15 Oct 2010 14:15:00 -0700 (PDT) Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D7F4140BB9; Fri, 15 Oct 2010 15:23:21 -0600 (MDT) Message-ID: <4CB8C4A4.5090402@stpeter.im> Date: Fri, 15 Oct 2010 15:16:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: =JeffH References: <4CB8C142.4030003@KingsMountain.com> In-Reply-To: <4CB8C142.4030003@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050809020007080100050307" Cc: IETF cert-based identity Subject: Re: [certid] some info from SSL labs cert survey data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:15:02 -0000 This is a cryptographically signed message in MIME format. --------------ms050809020007080100050307 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/15/10 3:01 PM, =3DJeffH wrote: > Here's some quick numbers. Thanks, Jeff. Numbers are good. > all 867361 have a "CN=3D" in the subject name (CN-ID). I'd be curious how many have Common Names that are intended to be DNS domain names like "www.example.com" and how many have plain old names like "Example Systems, Inc.". But I suppose I could poke around the dataset myself. :) Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms050809020007080100050307 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAx NTIxMTYyMFowIwYJKoZIhvcNAQkEMRYEFPvevAS5HHDLZJqXTFrA3KYBBLPlMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCkSUuGN/+8D5LSJ5TKRTOmbkjauSUl6TzUxHouWRhqm/vgu/+s9moN420E 8ZjSFwaN42znVJcdOMhSId/bMIBvi8aadyZLLdoJB0VIPTBXZYJaZt4suxfPNbqxJCQ6Jfs0 v133mjFjDa3un0yyWrzNicOm7ygM62QZOlsudeyBRMZPZOLHAn9swPWI5ulM+rB4uCOTn1va GjcxefsDwhK7iWjRkCGgWPK77VD1iUL/dcVs84kqXy/0qGa7S0tCtuasVg752kautVvlXgzo kWnFSZ8lTAHowtQaNbFMHz6JjZPFkHLFRQH0ysOnQ8gC9IvH5gTcYe7bN1sNnxE7qZ8LAAAA AAAA --------------ms050809020007080100050307-- From jwkckid1@ix.netcom.com Fri Oct 15 14:48:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 622CF3A6BC4 for ; Fri, 15 Oct 2010 14:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.44 X-Spam-Level: X-Spam-Status: No, score=-0.44 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_50=0.001] 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 wdlGaLoWIPkm for ; Fri, 15 Oct 2010 14:48:48 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id 0A1793A68E0 for ; Fri, 15 Oct 2010 14:48:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=K5NkTBCHfQJjp7VatcVSPj098ibNiqWo18uhKrwgA1e+m6Lr6XMBk2YQ+p2E6osn; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.35] (helo=elwamui-huard.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P6sAE-0002A9-2S; Fri, 15 Oct 2010 17:50:10 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 15 Oct 2010 17:50:09 -0400 Message-ID: <11037043.1287179409946.JavaMail.root@elwamui-huard.atl.sa.earthlink.net> Date: Fri, 15 Oct 2010 16:50:09 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: =JeffH , IETF cert-based identity Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606880cfd3295444d9bc941e26febf3feb49a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.35 Subject: Re: [certid] some info from SSL labs cert survey data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2010 21:48:49 -0000 Jeff and all, Are you saying that self-singed certs are not valid? If so, how on earth did they get into the dbase? -----Original Message----- >From: =JeffH >Sent: Oct 15, 2010 4:01 PM >To: IETF cert-based identity >Subject: [certid] some info from SSL labs cert survey data > >I've done some modest poking around the SSL labs cert survey data, below's some >numbers. > >First, the dataset has 867361 domains along with data extracted from their >certs (one row per domain). The details on how Ivan selected the domains are here.. > > > >That explanation hints that most all the certs represented in the dataset would >be "valid" certs. However, there's ~150k more entries in the dbase than the >~720K valid certs he observed. Though, there's ~150k apparently "self-signed" >certs in the dbase, so perhaps that's what's filling out the dbase. > > >Here's some quick numbers.. > > > >all 867361 have a "CN=" in the subject name (CN-ID). > >None appear to have more than one CN-ID > > > >392497 (45%) use the subjectAltName field for at least one altName (of some >type (I haven't yet investigated whether he gathered more than only DNS-IDs >(but upon quick browsing it looks like they are most all DNS-IDs))) > >6487 (0.75%) have > 5 altNames (of some type) > >145 (0.02%) have > 50 altNames (of some type) > > > >33831 (4%) use a wildcard in their name in some fashion (they sometimes are in >CN-ID, or subjectAltName, or both it appears upon quick browsing) > > > > >153113 (18%) have a null trustAnchor field - suggesting they are self-signed(?) > >99673 (11%) have subjectCommonName == issuerCommonName -- most self-signed(?) > >52929 (6%) have subjectCommonName != issuerCommonName and a null trustAnchor >field. > >0 have subjectCommonName == issuerCommonName and a non-null >trustAnchor field. > > >There are 86 distinct trustAnchor names in the data set. > > > >HTH, > >=JeffH > > > > > > > > > > > > > > > > > > >_______________________________________________ >certid mailing list >certid@ietf.org >https://www.ietf.org/mailman/listinfo/certid Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From Jeff.Hodges@KingsMountain.com Sat Oct 16 21:39:30 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD6AF3A68D5 for ; Sat, 16 Oct 2010 21:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.271 X-Spam-Level: X-Spam-Status: No, score=-100.271 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_50=0.001, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, SARE_URI_EQUALS=1.666, URI_HEX=0.368, 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 RZMSBe76U6ZV for ; Sat, 16 Oct 2010 21:39:22 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 487A13A686B for ; Sat, 16 Oct 2010 21:39:22 -0700 (PDT) Received: (qmail 25905 invoked by uid 0); 17 Oct 2010 04:40:47 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 17 Oct 2010 04:40:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=aqyWwMf3Kt7sOJyWaiHpI+4h1JC9laGjyKme1nVmFZ+G8BFZxL5UyQxy03QEUkrwU5M0A8SkKj7+mEj+BeAiPfSiCqCeUhEmJbycrtymfVrnOVnhik1yPpHfqk7RrMJQ; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P7L38-00074W-RG for certid@ietf.org; Sat, 16 Oct 2010 22:40:47 -0600 Message-ID: <4CBA7E4C.1030609@KingsMountain.com> Date: Sat, 16 Oct 2010 21:40:44 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Oct 2010 04:39:32 -0000 >> all 867361 have a "CN=3D" in the subject name (CN-ID). > > I'd be curious how many have Common Names that are intended to be DNS > domain names like "www.example.com" and how many have plain old names > like "Example Systems, Inc.". Ok, I extracted all CN-IDs (subjectCommonName) in SSL Labs Survey Data, h= acked=20 up a regex, wrapped it with some perl, and found there's 1151 "weird" CN-= ID=20 values in the data ( 0.13% ). These are string values that don't match a = regex=20 describing a optional-whitespace-wrapped LDH (Letter-Digit-Hyphen) domain= name=20 (note that an IDN won't match this (one's included below)). Some examples highlighting the variety of types I observe when browsing t= he=20 "weird" CN-ID values are below. Note that I didn't try verifying this dat= a (eg=20 by checking that the subjectCommonName column matched the CN attributes v= alue=20 in the subject column in the dbase table, nor by going and querying the s= ervers=20 and verifying the cert returned matches the dbase entries). =3DJeffH ALL IN ONE services.acheckamerica.com suite.agile1.com www.etimeentry.c= om ALL=20 IN ONE iNDivia.net Net Services incelis Inc. intranet.zsi.at bibliothek.intranet.zsi.at webmail.intranet.zsi.at=20 wiki.intranet.zsi.at ztools.intranet.zsi.at=20 HTTP TLS/SSL Certificate self-signed Marty Ledgerwood www.southvalleywealth.org rsa-key 5418825488= =20 0162022008002919 68.185.19.85 Exchange Wildcard *.bluevalleyk12.org schoolcenter.bluevalleyk12.org www.bluevalleyk12.or= g (www|zeus).asap-solution.com 193.46.210.226 serveco-ua.com thenamelessdomain Server Certificate www.=C3=99=C2=86=C3=98=C2=B3=C3=98=C2=AA=C3=98=C2=B6=C3=99=C2=8A=C3=99=C2= =81-=C3=99=C2=84=C3=99=C2=83=C3=99=C2=85.com Yandex Serp PACKAGING TAPE www.airmovers.com www.carpetextractors.com www.cleanfrea= k.com=20 www.floorbuffers.com www.floorscrubbers.com www.packagingtapeinc.com=20 www.ptipackaging.com PACKAGING TAPE=20 Yandex Tiny Corba Services www.cebbank.com+2.5.4.5=3D#130f313030303030303030303131373438 THE INTERNATIONAL SOCIETY FOR TRAUMATIC STRESS STUDIES istss.info istss.o= rg=20 www.istss.org THE INTERNATIONAL SOCIETY FOR TRAUMATIC STRESS STUDIES ownitsch.de HTTPS Certificate =20 \x00*\x00.\x00p\x00s\x00e\x00a\x00l\x00o\x00c\x00a\x00l\x00s\x00.\x00o\x0= 0r\x00g SOCIETY OF VERTEBRATE PALEONTOLOGY vertpaleo.info vertpaleo.org=20 www.vertpaleo.org SOCIETY OF VERTEBRATE PALEONTOLOGY NET LOGISTICS PTY. LTD. secure.netlogistics.com.au www.netlogistics.com.a= u=20 www.turboservers.com.au NET LOGISTICS PTY. LTD. PLATINUM ACQUISITIONS www.4closureprofits.com www.4closures4profit.com = www.4ecloser.com www.bestdealsonforeclosures.com=20 www.bspeaksforeclosesureinvest.com www.easyforeclosurefortune.com=20 www.easyforeclosureinvestingsecretsrevealed.com=20 www.easyforeclosurestrategies.com www.easystreetforeclosureinvesting.com = www.estatereposite.com www.fastcashforeclosures.com=20 www.forecloserinvestment101.com www.foreclosesimpleinvest.com=20 www.foreclosure-investoptions.com www.foreclosurebeyond.com=20 www.foreclosurecashsecrets.com www.foreclosurecottage.com=20 www.foreclosureforprofits.com www.foreclosureinformations.com=20 www.foreclosureinvestingforyou.com www.foreclosureinvestor5000.com=20 www.foreclosurepatriot.com www.foreclosureprosperity.com www.foreclosureq= ue.com=20 www.foreclosurerewards.com www.foreclosures-pal.com www.foreclosures4agra= nd.com=20 www.foreclosureuniversal.com www.foxforeclosureinvesting.com=20 www.freesimpleforeclosure.com www.grandforeclosureinvesting.com=20 www.homesforeclosuresale.com www.hugeforclosureprofit.com=20 www.investforclosure.com www.investinforeclosurestoday.com=20 www.investinginewforeclosures.com www.investinginfoforeclosures.com=20 www.investingnforclosures.com www.investingwithforeclosures.com=20 www.newforeclosureinfo.com www.newsecretforeclosures4less.com=20 www.power-fore-closures.com www.profitfromforeclosure.com=20 www.reclaimproperties.com www.riskfreeforeclosurefortunes.com=20 www.seforclosures.com www.simple4closureinvesting.com=20 www.simpleforeclosureinvest.com www.topforeclosuredata.com=20 www.unlockthevaultforeclosers.com www.winwininforeclosures.com PLATINUM=20 ACQUISITIONS=20 --- end From mrex@sap.com Mon Oct 18 06:22:36 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79DDF3A6AB8 for ; Mon, 18 Oct 2010 06:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.955 X-Spam-Level: X-Spam-Status: No, score=-7.955 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_URI_EQUALS=1.666, URI_HEX=0.368] 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 Y8exMvSHHINC for ; Mon, 18 Oct 2010 06:22:35 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 3D0FF3A6BC3 for ; Mon, 18 Oct 2010 06:22:35 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o9IDO2wv025955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Oct 2010 15:24:02 +0200 (MEST) From: Martin Rex Message-Id: <201010181324.o9IDO1jX024285@fs4113.wdf.sap.corp> To: Jeff.Hodges@KingsMountain.com (=JeffH) Date: Mon, 18 Oct 2010 15:24:01 +0200 (MEST) In-Reply-To: <4CBA7E4C.1030609@KingsMountain.com> from "=JeffH" at Oct 16, 10 09:40:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-AntiVirus: checked by Avira MailGate (version: 3.1.2; AVE: 8.2.4.66; VDF: 7.10.12.56; host: virwal02); id=11009-QzciGv X-SAP: out Cc: certid@ietf.org Subject: Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 13:22:36 -0000 =JeffH wrote: > > www.cebbank.com+2.5.4.5=#130f313030303030303030303131373438 This is a correct CN-ID, with a RDName that contains two attribute-value pairs, CN + SerialNumber The plus instead of the comma indicates that attributes are part of the same RDName. -Martin From matt@mattmccutchen.net Mon Oct 18 10:43:22 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EE2F3A6E01 for ; Mon, 18 Oct 2010 10:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_00=-2.599, SARE_URI_EQUALS=1.666, URI_HEX=0.368] 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 UbsJ+uzpCjZZ for ; Mon, 18 Oct 2010 10:43:19 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by core3.amsl.com (Postfix) with ESMTP id 4EA543A6DAB for ; Mon, 18 Oct 2010 10:39:20 -0700 (PDT) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 4D6A0578059; Mon, 18 Oct 2010 10:40:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=Fl77ri61il5F9CHFEskHA7ID/e/TH1bbDCOCtGJ2Ymk RzsLsra/bgXL1o3/zDiPbEb/gPD9Rpg7yg4YK6HAvUsKs8RyRHiLI7z71fz8Dh5U /FgfN976mV6LF9UCyrA0DCcYa5CJM6Y4pGzgusFOhO6vSxUzRKxRp8Sw+JrQUfZw = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=pVn0BcDJxTk+r/dPgHrErVBJmxI=; b=gNFprIp/d8 JwWUpqG5krE3GY+lBrSv90+ZTg++zgQU1n+qUy7vnAb6p/sCamc0rK7Ei/RKzHXz XYUXVlMvWgkCDkpjKeejNq6UiXLJNoE7L3ZdP78qD537UcYyk8MBr6NZmfDc+cxJ r3WcPBXe9TvJaLkqlssobckUtQh4503ic= Received: from [129.2.249.209] (ml2.student.umd.edu [129.2.249.209]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPA id CEBAC578071; Mon, 18 Oct 2010 10:40:20 -0700 (PDT) From: Matt McCutchen To: mrex@sap.com, =JeffH , certid@ietf.org In-Reply-To: <201010181324.o9IDO1jX024285@fs4113.wdf.sap.corp> References: <201010181324.o9IDO1jX024285@fs4113.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Date: Mon, 18 Oct 2010 13:40:19 -0400 Message-ID: <1287423619.1962.14.camel@mattlaptop2.local> Mime-Version: 1.0 X-Mailer: Evolution 2.30.4 Content-Transfer-Encoding: 7bit Subject: Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Oct 2010 17:43:22 -0000 On Mon, 2010-10-18 at 15:24 +0200, Martin Rex wrote: > =JeffH wrote: > > > > www.cebbank.com+2.5.4.5=#130f313030303030303030303131373438 > > This is a correct CN-ID, > with a RDName that contains two attribute-value pairs, CN + SerialNumber > > The plus instead of the comma indicates that attributes are part > of the same RDName. I guess this is a bug in the parser used for the survey: it assumed that an RDN starting with "CN=" contained only a CN and did not properly split multiple AVAs. -- Matt From Jeff.Hodges@KingsMountain.com Mon Oct 18 17:08:19 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7ACC3A6BC4 for ; Mon, 18 Oct 2010 17:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.092 X-Spam-Level: X-Spam-Status: No, score=-101.092 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_URI_EQUALS=1.666, URI_HEX=0.368, 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 TMRoePYjXAk3 for ; Mon, 18 Oct 2010 17:08:18 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id E03893A6A93 for ; Mon, 18 Oct 2010 17:08:17 -0700 (PDT) Received: (qmail 18577 invoked by uid 0); 19 Oct 2010 00:09:47 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 19 Oct 2010 00:09:47 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=fmc4+1zgm+KGmTeWdK5OMFcBwSRNRGiAqb818BnvwBuCvqS7KgXibfnuJoLn9ala2yCs2Ocf1kUthmhJ12X2c7JNRtTlXuA2/WBA3sH6kGhwsnPiiEQ9kfJLOd4V0Z0H; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P7zlz-0004Yn-6y for certid@ietf.org; Mon, 18 Oct 2010 18:09:47 -0600 Message-ID: <4CBCE1C9.3090104@KingsMountain.com> Date: Mon, 18 Oct 2010 17:09:45 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 00:08:20 -0000 So, I got a couple of bug reports on my original msg in this thread (thanks!). It turns out (a) my regex was sorta broken, and (b) the subjectCommonName column Ivan has in the dbase table has all the "CN" attr values smooshed into it. So the certs with a subject with just one CN attr-value-assertion (AVA) will (likely) have a reasonable-looking value (but not necessarily a domain name) in the subjectCommonName column, but a subject with multiple CN AVAs will have an odd-looking value in subjectCommonName (like the ones I included in my orig msg). Now, as Martin pointed out, the ones that look like this.. www.cebbank.com+2.5.4.5=#130f313030303030303030303131373438 ..seem to be an RDName that's comprised of two AVAs, and in the/this DN string representation, they're conjoined by a "+" char. And yes, as Matt noted, it seems there's a bug in the parser used for the survey where it apparently assumed that an RDN beginning with a "CN=" contains only a CN AVA. Also, upon examining subject names more closely, it appears it properly parsed RDNs where the CN AVA appears after the first AVA in the RDN. E.g... 2.5.4.5=#13083431343038353030+CN=secure.capis.com ..yielded "secure.capis.com" in the subjectCommonName column, surprisingly enough. So, anyway, yes, there are subject name with CN AVAs that have values /other than/ dns domain names. Sometimes the cert has both natural-language CN values (i.e. one or more) along with domain name values, sometimes just natural-language values, but largely the CN values in the overall data are domain name values. With a new regex, I count 622 cert entries with at least one natural-language CN value (they may also have CN values containing domain name-like constructs). e.g... CN=USMOTIVATION CN=MONARCH MARKETING SERVICES (MONARCH GRAPHICS, INC) CN=NORTH CAROLINA INFORMATION DATA, INC. I hear tell that the regex-like esatz CN-ID values, e.g... (www|zeus).asap-solution.com ..are due to at least one browser supporting (but no more?) such constructs. =JeffH From Jeff.Hodges@KingsMountain.com Tue Oct 19 10:05:38 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F6AF3A68CF for ; Tue, 19 Oct 2010 10:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.097 X-Spam-Level: X-Spam-Status: No, score=-103.097 tagged_above=-999 required=5 tests=[AWL=1.168, BAYES_00=-2.599, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, 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 AdYaoA3fV+of for ; Tue, 19 Oct 2010 10:05:37 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id EBB803A68C2 for ; Tue, 19 Oct 2010 10:05:36 -0700 (PDT) Received: (qmail 8510 invoked by uid 0); 19 Oct 2010 17:07:08 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 19 Oct 2010 17:07:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=tdTDDHvcIQESmo3gG6J1IX+62tE2u7OxiKQbdu4wIfK5pUXQ3hqselectPyrnzTP0eL6Tifdz41DGuRPAhQgZCuGDZOLdMRsbb3CNw8DkcISwTuOqspKYcNoOp/0YDGh; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P8FeV-0005WX-KS; Tue, 19 Oct 2010 11:07:07 -0600 Message-ID: <4CBDD03A.4060406@KingsMountain.com> Date: Tue, 19 Oct 2010 10:07:06 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity , Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:05:38 -0000 > There sure are some bizarre things in CNs... is there any chance you could > implement what Marcus Ranum calls "artificial stupidity" in your anomaly- > detection, create a filter that accepts all standard DN component styles and > then kick out certs that don't pass the filter? that's essentially what I did yesterday tho I refined the regex a bit this morning. Here's the (perl) regex.. /[Cc][Nn]=(?!([\-\w\*]+\.)+[\-\w]+)/ ..which appears to also work fine in NEdit. What it does (my intent anyway, I am not an awesome regex master) is recognize any CN-ID pattern that is /not/ syntatically a dot-separated LDH (letter digit hyphen) DNS domain name. Employed thus.. while (<>) { if ( /[Cc][Nn]=(?!([\-\w\*]+\.)+[\-\w]+)/ ) { print "\n"; print; }; }; I think it does what you suggest below. What I fed into the above loop is a txt file output by querying the raw database table for all contacted domains and returned cert subject values (one pair per line, would of course work on a file with just subjects in it). > In other words instead of > trying to create a regex to detect all the bizarre things that turn up in > there, create one to pass normal DNs and treat everything that doesn't pass as > an anomaly? yes, done. So there appear to (actually) be 433 (I'd mis-counted yesterday (haste makes waste)) such subject DNs (622 is an incorrect count AFAICT today). Note that these subject DNs may /also/ contain syntactically correct CN-ID values (many do, some do not). > It'd be interesting to see what sort of stuff is floating around > out there... of course. Note that the data is nominally available upon request as Ivan has blogged, which I posted here earlier here.. [certid] fyi: Ivan Ristic / Qualsys SSL Labs release raw data from the Internet SSL survey http://www.ietf.org/mail-archive/web/certid/current/msg00484.html There's a shrink-wrap EULA that Ivan wants folks to agree to before obtaining the data and I haven't groveled thru it enough to tell whether it's legit to just post all 433 results (or any other full result set) to the a public list & archive such as this. Also note that he/qualsys may re-run the survey periodically. This is also the intention of the EFF folks and their "TLS/SSL observatory" (tho they have yet to publicly release their data). (note also that their survey data collection methodologies differ -- EFF folks say they "NMAPed Internet for hosts listening on tcp 443", where Ivan queried publicly registered domain names in a (large) subset of all TLDs) HTH, =JeffH From Jeff.Hodges@KingsMountain.com Tue Oct 19 10:22:56 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B77D3A68C2 for ; Tue, 19 Oct 2010 10:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.114 X-Spam-Level: X-Spam-Status: No, score=-102.114 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 u29OWP+4kSJf for ; Tue, 19 Oct 2010 10:22:54 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 8CA333A68C0 for ; Tue, 19 Oct 2010 10:22:54 -0700 (PDT) Received: (qmail 13850 invoked by uid 0); 19 Oct 2010 17:24:25 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 19 Oct 2010 17:24:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=ACaf/3Ea3zLYWEm2xLmEJmRRnsFcKNUvpbmNvajhGau1ofzsvRFuHISy91UpeXy7frKDcynINAPpL/aXFwWQMNWkiVwJC0HfINuZkZ2dh+29GD/NuFWruavYNuPTXydW; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P8FvF-00012M-Ie; Tue, 19 Oct 2010 11:24:25 -0600 Message-ID: <4CBDD448.1060004@KingsMountain.com> Date: Tue, 19 Oct 2010 10:24:24 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: IETF cert-based identity , Peter Gutmann Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2010 17:22:56 -0000 a further note on the regex.. /[Cc][Nn]=(?!([\-\w\*]+\.)+[\-\w]+)/ regex aficionados will note that there are subtle issues with the regex -- e.g. "([\-\w\*]+\.)+[\-\w]+)" -- the latter component doesn't /precisely/ describe DNS LDH domain name syntax. for instance, \w matches underscore, and thus the regex matches labels with underscore appearing anywhere in them, but (current) DNS LDH domain name syntax allows for underscore in only the first char position of a label. The regex also doesn't check for other first-char-of-label restrictions, and also matches wildcards anywhere in labels (which is a subtlety we've been debating). However, I feel that for my present back-of-the-envelope quick looksee in the subject name data, that thar regex above is Good Enough. Of course if others want to be more precise, go for it. =JeffH From Jeff.Hodges@KingsMountain.com Wed Oct 20 09:00:02 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 282A73A6914 for ; Wed, 20 Oct 2010 09:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 mnzlVOwTVMwb for ; Wed, 20 Oct 2010 09:00:00 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 6675D3A684D for ; Wed, 20 Oct 2010 09:00:00 -0700 (PDT) Received: (qmail 5702 invoked by uid 0); 20 Oct 2010 16:01:33 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy3.bluehost.com with SMTP; 20 Oct 2010 16:01:33 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=TYKk91uWuOLFEfcjNCtjYc909AaOVrIBTubDy/i56JqWTxSwtPDp9C5pcDbIV2+mtvhw+1EexlCGt4b2NL9PW4x7k+9mBEPhbph/XnTZkVW3M9kb9mxVDW9mqlVjgtu5; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P8b6a-0002Ge-Ru; Wed, 20 Oct 2010 10:01:33 -0600 Message-ID: <4CBF125C.6010704@KingsMountain.com> Date: Wed, 20 Oct 2010 09:01:32 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Peter Gutmann , IETF cert-based identity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:00:02 -0000 >>ALL IN ONE services.acheckamerica.com suite.agile1.com www.etimeentry.com ALL >>IN ONE > > Duplicate instances of the same AVA at both ends of the DN (I'd like to see > that go in an LDAP directory!). > >>intranet.zsi.at bibliothek.intranet.zsi.at webmail.intranet.zsi.at >>wiki.intranet.zsi.at ztools.intranet.zsi.at > > This contains a DN with components thrown together in more or less arbitrary > order, again with CNs at both the start and end of the DN. > >>PACKAGING TAPE www.airmovers.com www.carpetextractors.com www.cleanfreak.com >>www.floorbuffers.com www.floorscrubbers.com www.packagingtapeinc.com >>www.ptipackaging.com PACKAGING TAPE > > Another double-ended DN with all sorts of bizarro (non-CN) components all over > it. > Yes, those are "odd", and as previously noted, the strings you're quoting above are comprised of extracted & concatenated-with-space-separators CN values that Ivan "smooshed" all together into one column ("subjectCommonName") in his database table. [If folks want to poke at the data themselves, request it from Ivan http://www.ietf.org/mail-archive/web/certid/current/msg00484.html ] fyi/fwiw, I count 946 certs in the dbase with more than one "CN" AVA in the subject DN, out of a total of 867361, so << 1%. WRT "Duplicate instances of the same AVA at both ends of the DN...", perhaps RobS can provide some rationale for this practice? Yes, they obviously aren't backing their CA databases with an X.500-based directory. I suspect hardly anyone (or even no-one) does so. =JeffH From stpeter@stpeter.im Wed Oct 20 09:34:49 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AC6B3A68CE for ; Wed, 20 Oct 2010 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 Nk6KAH5PGk35 for ; Wed, 20 Oct 2010 09:34:46 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id E61F73A69DC for ; Wed, 20 Oct 2010 09:34:36 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C0AE040074 for ; Wed, 20 Oct 2010 10:43:34 -0600 (MDT) Message-ID: <4CBF1A75.4010205@stpeter.im> Date: Wed, 20 Oct 2010 10:36:05 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: IETF cert-based identity X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080409030905010709020704" Subject: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 16:34:49 -0000 This is a cryptographically signed message in MIME format. --------------ms080409030905010709020704 Content-Type: multipart/mixed; boundary="------------020305030605090701020109" This is a multi-part message in MIME format. --------------020305030605090701020109 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Finally! The diff is here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-saintandre-tls-server-id-check= -10 -------- Original Message -------- Subject: I-D Action:draft-saintandre-tls-server-id-check-10.txt Date: Wed, 20 Oct 2010 09:30:02 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) Author(s) : P. Saint-Andre, J. Hodges Filename : draft-saintandre-tls-server-id-check-10.txt Pages : 46 Date : 2010-10-20 Many application technologies enable a secure connection between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies best current practices for representing and verifying the identity of application services in such interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-= 10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --------------020305030605090701020109 Content-Type: Message/External-body; name="draft-saintandre-tls-server-id-check-10.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-saintandre-tls-server-id-check-10.txt" Content-Type: text/plain Content-ID: <2010-10-20092452.I-D@ietf.org> --------------020305030605090701020109 Content-Type: text/plain; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSS1ELUFu bm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2VAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKSW50ZXJuZXQtRHJhZnQg ZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8v ZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCg== --------------020305030605090701020109-- --------------ms080409030905010709020704 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy MDE2MzYwNVowIwYJKoZIhvcNAQkEMRYEFKyhKl8lSN6+AdmxMbKpqmzV0MwCMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQAmYKg+iYsA4Y4S5F6D7M2i09HZBhDKa+FxJw+Js/uCNjx4R83g44jXJaFK JReSim7y5OQ6psZ6wDPhdOEwHzkdgMVk6avDKDnZqJLsvtXg8MI38ymIFo80ikHReWdniigs TlRUCNI/M3LBIjNDlopV9erunka+uRY7k0BDc7YnwF+LWupqMK/r+rxhGQN5dOywyiBEi1Xc ljHbDEo4MwcWr+5AWuKtc/nD0kBEMR76K5ePCuKdXB9fOY9Eu5bTnPcaoosl1Ac44mVl4bZh xi3txxtGG61ADd8S/FY9a7W3ecdcj9PZARycpFWohDSQvfPRx/nEqsHWW+nJhYhvwWX3AAAA AAAA --------------ms080409030905010709020704-- From Jeff.Hodges@KingsMountain.com Wed Oct 20 10:06:32 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAE2E3A6921 for ; Wed, 20 Oct 2010 10:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.118 X-Spam-Level: X-Spam-Status: No, score=-102.118 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 DtnHzI7KzbiZ for ; Wed, 20 Oct 2010 10:06:31 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 5A4193A68D5 for ; Wed, 20 Oct 2010 10:06:31 -0700 (PDT) Received: (qmail 20793 invoked by uid 0); 20 Oct 2010 17:08:04 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy2.bluehost.com with SMTP; 20 Oct 2010 17:08:04 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=NkIYtbMZaLE+WXuicWkp92JEpoBMAsYdgy9OnOzUCPzkZ+oBucwiCx7sPvNWDAQ6NjB2TDzC9VmbwzA6lMexp5ypJc91CJzGnTOgl77m0wP1/af9wbi7IrxRLui3cFBM; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.136.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1P8c8y-0003MM-93; Wed, 20 Oct 2010 11:08:04 -0600 Message-ID: <4CBF21F4.6000008@KingsMountain.com> Date: Wed, 20 Oct 2010 10:08:04 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Cc: IETF cert-based identity Subject: [certid] next steps for -tls-server-id-check ? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:06:32 -0000 So what are our next formal steps for -tls-server-id-check ? thanks, =JeffH From stpeter@stpeter.im Wed Oct 20 10:16:17 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B583A68F6 for ; Wed, 20 Oct 2010 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, 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 7wiaaK+1A-MN for ; Wed, 20 Oct 2010 10:16:16 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 182403A68A4 for ; Wed, 20 Oct 2010 10:16:16 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3930E40074; Wed, 20 Oct 2010 11:25:15 -0600 (MDT) Message-ID: <4CBF243B.1040800@stpeter.im> Date: Wed, 20 Oct 2010 11:17:47 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: =JeffH References: <4CBF21F4.6000008@KingsMountain.com> In-Reply-To: <4CBF21F4.6000008@KingsMountain.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000604050204020202090102" Cc: IETF cert-based identity Subject: Re: [certid] next steps for -tls-server-id-check ? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 17:16:18 -0000 This is a cryptographically signed message in MIME format. --------------ms000604050204020202090102 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/20/10 11:08 AM, =3DJeffH wrote: > So what are our next formal steps for -tls-server-id-check ? Alexey, our sponsoring AD, is going to review it before IETF 79 and let us know how he would like to proceed. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000604050204020202090102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy MDE3MTc0N1owIwYJKoZIhvcNAQkEMRYEFE/YBRlL+A1r6WONB8RdgRjupGc8MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCfYNo2VzhnyHovZjy64fDujLOhao+aoQrhbthVzpGqDFn8R+z2KxNt8TZR ATQxPdV8pIx4eWY0wJ/aZRfagnIyNvH7LnUF++2rn+rn4b+aDSpnmnREBNztlowQgVmQ2knH chXxgZqeK/LmyPTSl80rOk7wQ559UeFkeDmpy58JrCYu+QT+kFsisWW3AuvjttqfSvxka6Vz NlB1/Cn6Rjn4yPajnlzQHjnO2nL6Agt75GnWYeGASKw6Itrk7j0YiwpetMSXecjSCl5FDi3l jgOZWz3QX9V64Pe2r8thVcVUMLcPoTuYB1o4cMYyVqZ7eHvAHPjnD1Dc0cntxf+V0LY0AAAA AAAA --------------ms000604050204020202090102-- From alexey.melnikov@isode.com Wed Oct 20 11:31:50 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21AA3A6827 for ; Wed, 20 Oct 2010 11:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, 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 R1QTsa95Ru2p for ; Wed, 20 Oct 2010 11:31:41 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 24CE23A681B for ; Wed, 20 Oct 2010 11:31:40 -0700 (PDT) Received: from [172.16.2.130] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 20 Oct 2010 19:33:12 +0100 Message-ID: <4CBF35C3.5000405@isode.com> Date: Wed, 20 Oct 2010 19:32:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =JeffH References: <4CBF21F4.6000008@KingsMountain.com> In-Reply-To: <4CBF21F4.6000008@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF cert-based identity Subject: Re: [certid] next steps for -tls-server-id-check ? X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 18:31:50 -0000 =JeffH wrote: > So what are our next formal steps for -tls-server-id-check ? I will try to review the document before November 1st and will decide if the document needs another IETF LC or not. I will also be looking for a document shepherd. From eddy_nigg@startcom.org Wed Oct 20 12:44:50 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C773A68A0 for ; Wed, 20 Oct 2010 12:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001] 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 4Tpd94Ckvr5z for ; Wed, 20 Oct 2010 12:44:48 -0700 (PDT) Received: from mta1.internal.startcom.org (apache-7.startcom.org [192.116.242.7]) by core3.amsl.com (Postfix) with ESMTP id E06903A67DF for ; Wed, 20 Oct 2010 12:44:47 -0700 (PDT) Received: from apache-2.internal.startcom.org (apache-2.internal.startcom.org [192.168.0.2]) by mta1.internal.startcom.org (8.13.8/8.13.8) with ESMTP id o9KJkF4S014617 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Oct 2010 21:46:19 +0200 Message-ID: <4CBF4705.4040604@startcom.org> Date: Wed, 20 Oct 2010 21:46:13 +0200 From: "Eddy Nigg (StartCom Ltd.)" Organization: StartCom Ltd. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2pre Thunderbird/3.1.4 MIME-Version: 1.0 To: "Hodges, Jeff" References: <44D08E6900CFC84288DDB4F41852C87A858B53F20D@DEN-MEXMS-001.corp.ebay.com> In-Reply-To: <44D08E6900CFC84288DDB4F41852C87A858B53F20D@DEN-MEXMS-001.corp.ebay.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060600040900070907080402" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (mta1.internal.startcom.org [192.168.0.15]); Wed, 20 Oct 2010 21:46:20 +0200 (IST) X-Mailman-Approved-At: Wed, 20 Oct 2010 13:17:20 -0700 Cc: certid@ietf.org Subject: Re: [certid] [cabfman] fyi: newly revised version: draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 19:59:20 -0000 This is a cryptographically signed message in MIME format. --------------ms060600040900070907080402 Content-Type: multipart/alternative; boundary="------------050906090408020405040307" This is a multi-part message in MIME format. --------------050906090408020405040307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/20/2010 08:28 PM, From Hodges, Jeff: > o Move away from including and checking strings that look like > domain names in the subject's Common Name. I applaud this recommendation since this has never been part of the=20 standard in first place and only was meant as a temporary bridge during=20 moving from x.509 version 2 to version 3. > o Move away from the issuance of so-called wildcard certificates > (e.g., a certificate containing an identifier for > "*.example.com"). However I'm not sure why wild cards should be prohibited, since this is=20 perfectly standard compliant. There are valid use-cases for wild cards=20 and in fact some of the biggest companies on the Internet are prevented=20 from using EV certificates exactly because of this prohibition (to use=20 wild cards with EV). I suggest to reconsider this recommendation. Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. XMPP: startcom@startcom.org Blog: Join the Revolution! Twitter: Follow Me --------------050906090408020405040307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 10/20/2010 08:28 PM, From Hodges, Jeff:
   o  Move away from including and checking strings =
that look like
      domain names in the subject's Common Name.

I applaud this recommendation since this has never been part of the standard in first place and only was meant as a temporary bridge during moving from x.509 version 2 to version 3.

   o  Move away from the issuance of so-called wildc=
ard certificates
      (e.g., a certificate containing an identifier for
      "*.example.com").

However I'm not sure why wild cards should be prohibited, since this is perfectly standard compliant. There are valid use-cases for wild cards and in fact some of the biggest companies on the Internet are prevented from using EV certificates exactly because of this prohibition (to use wild cards with EV). I suggest to reconsider this recommendation.

Regards=C2=A0
=C2=A0
Signer:=C2=A0 Eddy Nigg, COO/CTO
=C2=A0 StartCom Ltd.
XMPP:=C2=A0 startcom@startcom.= org
Blog:=C2=A0 Join the Revolution!=
Twitter:=C2=A0 Follow Me
=C2=A0

--------------050906090408020405040307-- --------------ms060600040900070907080402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIU5jCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIHUzCCBjugAwIBAgICAIgwDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDA5MjEyMTU3NDha Fw0xMjA5MjIwNjQzMzVaMIHtMSAwHgYDVQQNExcyNjE1NTUtTmhOYmUxTWJsVTV0THpkaTEL MAkGA1UEBhMCSUwxEDAOBgNVBAgTB0hhRGFyb20xDjAMBgNVBAcTBUVpbGF0MTEwLwYDVQQK EyhTdGFydENvbSBMdGQuIChTdGFydCBDb21tZXJjaWFsIExpbWl0ZWQpMSwwKgYDVQQLEyNT dGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRlIE1lbWJlcjESMBAGA1UEAxMJRWRkeSBOaWdn MSUwIwYJKoZIhvcNAQkBFhZlZGR5X25pZ2dAc3RhcnRjb20ub3JnMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEA203fvaeKfnxrxqF+ZIbysgQkHUKEAc+YllKqHO9BYcllj140 OcMHr1Pci9Wl8AGNoCJXdMBsZYc66R86cfCJPv/U7p3ItVkWHjNrzAo3HSNfbFFNqAn5IfnU zPDYK6soDkgG8YMzPj6lEvpG7kv2zN7IhOfJIvaivviy886ms1Mb8sR9USKNwmrjHPIfDz+A SqHMmFKKiKcLeLa7WAQSKGQHuO/NmPdhGE/+asv8p4SDqVmYeuQt6QthuaDTxqdnR6mUWelp 6Ve+ANgU+jQS4nQUMc+EBp2Uj37EKDJQlhGOduqntZ6veQxGEDy4pYrfrYj1ASnblBIEAS0k e6EAHwIDAQABo4IDWjCCA1YwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYI KwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBRytFjF4caL09Ps/nvLxpM5duMwPzAfBgNV HSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zB8BgNVHREEdTBzgRZlZGR5X25pZ2dAc3Rh cnRjb20ub3JngRdjZXJ0bWFzdGVyQHN0YXJ0Y29tLm9yZ4EWd2VibWFzdGVyQHN0YXJ0Y29t Lm9yZ4EUc3VwcG9ydEBzdGFydGNvbS5vcmeBEmFkbWluQHN0YXJ0Y29tLm9yZzCCAUIGA1Ud IASCATkwggE1MIIBMQYLKwYBBAGBtTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBM dGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0 YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5 IGF2YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1Ud HwRcMFowK6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6Ap oCeGJWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEB BIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3Mz L2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMv c3ViLmNsYXNzMy5jbGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAptA3fz+SWXQr61ailpvDTcXK+SZqtbDM7gNA oGbNILjFEwi84rKFiFAES6MYs10aqD7yDeLR7muO9e/Wpa50UFHER/AJU1h1puMGwbVdx0sk Cbt3cHu/c3hTCQYdcIoa0WXhUMLF1Ttwy8LyjfrnLD0KaR/e5VHlzJqs8kepPnPTcXy1Uj2F i2g++pQzFxZxnWbsKT6+wiYym3lW3sYP/yqFBJb2yqkWgIwCxyvR4T6rMkzpTiCTyS24RhGo 3Jd7yrY94MovT6jp+vT34Kr3QTBDLwZmSn3LbRLsjEVMD9KtdB7K65Fj/cLiT2S74/Eett59 FNoGYyTxsdKPG/l/AjCCB1MwggY7oAMCAQICAgCIMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0 YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTAwOTIxMjE1NzQ4WhcNMTIwOTIyMDY0 MzM1WjCB7TEgMB4GA1UEDRMXMjYxNTU1LU5oTmJlMU1ibFU1dEx6ZGkxCzAJBgNVBAYTAklM MRAwDgYDVQQIEwdIYURhcm9tMQ4wDAYDVQQHEwVFaWxhdDExMC8GA1UEChMoU3RhcnRDb20g THRkLiAoU3RhcnQgQ29tbWVyY2lhbCBMaW1pdGVkKTEsMCoGA1UECxMjU3RhcnRDb20gVHJ1 c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxEjAQBgNVBAMTCUVkZHkgTmlnZzElMCMGCSqGSIb3 DQEJARYWZWRkeV9uaWdnQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBANtN372nin58a8ahfmSG8rIEJB1ChAHPmJZSqhzvQWHJZY9eNDnDB69T3IvVpfAB jaAiV3TAbGWHOukfOnHwiT7/1O6dyLVZFh4za8wKNx0jX2xRTagJ+SH51Mzw2CurKA5IBvGD Mz4+pRL6Ru5L9szeyITnySL2or74svPOprNTG/LEfVEijcJq4xzyHw8/gEqhzJhSioinC3i2 u1gEEihkB7jvzZj3YRhP/mrL/KeEg6lZmHrkLekLYbmg08anZ0eplFnpaelXvgDYFPo0EuJ0 FDHPhAadlI9+xCgyUJYRjnbqp7Wer3kMRhA8uKWK362I9QEp25QSBAEtJHuhAB8CAwEAAaOC A1owggNWMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQUcrRYxeHGi9PT7P57y8aTOXbjMD8wHwYDVR0jBBgwFoAUe4mc kpckoYRHAst0/C70rNwy5fMwfAYDVR0RBHUwc4EWZWRkeV9uaWdnQHN0YXJ0Y29tLm9yZ4EX Y2VydG1hc3RlckBzdGFydGNvbS5vcmeBFndlYm1hc3RlckBzdGFydGNvbS5vcmeBFHN1cHBv cnRAc3RhcnRjb20ub3JngRJhZG1pbkBzdGFydGNvbS5vcmcwggFCBgNVHSAEggE5MIIBNTCC ATEGCysGAQQBgbU3AQICMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5j b20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50 ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGR TGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2Yg dGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUg YXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAn hiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8v Y3JsLnN0YXJ0c3NsLmNvbS9jcnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2Ew QgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMu Y2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQEFBQADggEBAKbQN38/kll0K+tWopabw03FyvkmarWwzO4DQKBmzSC4xRMIvOKy hYhQBEujGLNdGqg+8g3i0e5rjvXv1qWudFBRxEfwCVNYdabjBsG1XcdLJAm7d3B7v3N4UwkG HXCKGtFl4VDCxdU7cMvC8o365yw9Cmkf3uVR5cyarPJHqT5z03F8tVI9hYtoPvqUMxcWcZ1m 7Ck+vsImMpt5Vt7GD/8qhQSW9sqpFoCMAscr0eE+qzJM6U4gk8ktuEYRqNyXe8q2PeDKL0+o 6fr09+Cq90EwQy8GZkp9y20S7IxFTA/SrXQeyuuRY/3C4k9ku+PxHrbefRTaBmMk8bHSjxv5 fwIxggPNMIIDyQIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIA iDAJBgUrDgMCGgUAoIICDjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0xMDEwMjAxOTQ2MTRaMCMGCSqGSIb3DQEJBDEWBBQTPWoqvG5J8EOCKF6bMNjQf6uC ozBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaQGCSsGAQQB gjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0 YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAiDCBpgYL KoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIC AIgwDQYJKoZIhvcNAQEBBQAEggEAlnMaZwfkyoHEyg/0jlJ8xcD2h/92pjuxRjpXu0kRu51V LGj8j7/ZvaNMZSx5Q2x49/puKu2KxKLhiXjhV2R0w6R0c8KOCZXJrVQ04+DkhdUza3lH1dqY DuM54DaU1eIXDKFwanuaSBeGrGXyh5hMabfvC7Xr6Y5JF7q+QAiqol+GKYAie2WOLXzNmsci DNiIOw33D42fSZv4SHwHXkjl+VgBaXWX5gL2JUd/LLSMhiME1pMANuc2YNDXzgq2AVcJ/eaj IElXFTFuKgN9nqpjyFZ03HH+LqQyh9A5lt5hLRjSDoEKqTN/ybTYLGDbPlrk4cqHGeTTpdfV qqWrmSZzowAAAAAAAA== --------------ms060600040900070907080402-- From fippo@mail.symlynx.com Wed Oct 20 13:51:46 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0F193A68D2; Wed, 20 Oct 2010 13:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 RkIdP-Kj+zhE; Wed, 20 Oct 2010 13:51:45 -0700 (PDT) Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by core3.amsl.com (Postfix) with ESMTP id D369F3A68C2; Wed, 20 Oct 2010 13:51:44 -0700 (PDT) Received: from [192.168.178.24] (p548BF91D.dip.t-dialin.net [84.139.249.29]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o9KKr1j8009306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Oct 2010 22:53:14 +0200 Message-ID: <4CBF56A9.1090503@mail.symlynx.com> Date: Wed, 20 Oct 2010 22:52:57 +0200 From: Philipp Hancke User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: XMPP Working Group References: <4CBF3310.8060801@stpeter.im> In-Reply-To: <4CBF3310.8060801@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Oct 2010 13:52:45 -0700 Cc: certid@ietf.org Subject: Re: [certid] [xmpp] Fwd: Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 20:51:46 -0000 There is a minor problem with that from the XMPP-s2s POV: it does not (explicitly) cover the case where a server verifies the identity of a peer server (see rfc3920bis 6.2.4 or the s2s section of XEP 0178 for details). AFAICS, the only difference is that the reference identifier is supplied by the peer instead of being constructed as described in section 4.2. Therefore, I'd propose adding the following note to the end of section 4.1: Note: Some application protocols such as XMPP perform the procedure described in this section when verifiying a server identity in a certificate presented by a TLS client. By this, and in contrast to the procedure described in the next subsection, the reference identifier is supplied by the peer (TLS client). Except for this and the inverted client-server role, the verification process remains unchanged. cheers philipp From jwkckid1@ix.netcom.com Wed Oct 20 14:16:10 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347F13A680C for ; Wed, 20 Oct 2010 14:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.447 X-Spam-Level: X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[AWL=-1.364, BAYES_50=0.001, FU_ENDS_2_WRDS=0.255, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] 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 PDvQcSWC3kAC for ; Wed, 20 Oct 2010 14:16:08 -0700 (PDT) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id D4F513A681E for ; Wed, 20 Oct 2010 14:16:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=f7MG3/VWrN4FUABvbydnvKu1BYSGvLZmVUW02E/d5Cyz+RAWAIqUJL6HyR9qHQZ2; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Transfer-Encoding:X-Mailer:Content-Type:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.41] (helo=elwamui-mouette.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1P8g2W-0003uY-Cc; Wed, 20 Oct 2010 17:17:40 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 20 Oct 2010 17:17:39 -0400 Message-ID: <16547012.1287609460099.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Date: Wed, 20 Oct 2010 16:17:39 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: "Eddy Nigg (StartCom Ltd.)" , "Hodges,Jeff" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 Content-Type: text/html; charset=UTF-8 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606887b4729d025e40e695412977339131041350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.41 Cc: certid@ietf.org Subject: Re: [certid] [cabfman] fyi: newly revised version: draft-saintandre-tls-server-id-check X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2010 21:16:10 -0000 Eddy and all,


-----Original Message-----
From: "Eddy Nigg (StartCom Ltd.)"
Sent: Oct 20, 2010 2:46 PM
To: "Hodges, Jeff"
Cc: certid@ietf.org
Subject: Re: [certid] [cabfman] fyi: newly revised version: draft-saintandre-tls-server-id-check


On 10/20/2010 08:28 PM, From Hodges, Jeff:
   o  Move away from including and checking strings that look like
      domain names in the subject's Common Name.


I applaud this recommendation since this has never been part of the standard in first place and only was meant as a temporary bridge during moving from x.509 version 2 to version 3.

Good point. 

   o  Move away from the issuance of so-called wildcard certificates
      (e.g., a certificate containing an identifier for
      "*.example.com").


However I'm not sure why wild cards should be prohibited, since this is perfectly standard compliant. There are valid use-cases for wild cards and in fact some of the biggest companies on the Internet are prevented from using EV certificates exactly because of this prohibition (to use wild cards with EV). I suggest to reconsider this recommendation.

 

I agree here.

Regards 
 
Signer:  Eddy Nigg, COO/CTO
  StartCom Ltd.
XMPP:  startcom@startcom.org
Blog:  Join the Revolution!
Twitter:  Follow Me
 


Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827
From rob.stradling@comodo.com Thu Oct 21 04:32:10 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 455713A677E for ; Thu, 21 Oct 2010 04:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.195 X-Spam-Level: X-Spam-Status: No, score=-4.195 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4] 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 bUnVrqsrcPVa for ; Thu, 21 Oct 2010 04:32:08 -0700 (PDT) Received: from ian.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by core3.amsl.com (Postfix) with ESMTP id A788D3A6452 for ; Thu, 21 Oct 2010 04:32:06 -0700 (PDT) Received: (qmail 13944 invoked by uid 1000); 21 Oct 2010 11:33:40 -0000 Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Thu, 21 Oct 2010 12:33:40 +0100 From: Rob Stradling To: certid@ietf.org Date: Thu, 21 Oct 2010 12:33:38 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.32-gentoo-r7; KDE/4.4.5; i686; ; ) References: <4CBF125C.6010704@KingsMountain.com> In-Reply-To: <4CBF125C.6010704@KingsMountain.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010211233.38528.rob.stradling@comodo.com> X-Mailman-Approved-At: Thu, 21 Oct 2010 06:41:15 -0700 Subject: Re: [certid] weird CN-IDs (subjectCommonName) in SSL Labs Survey Data X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Oct 2010 11:32:10 -0000 On Wednesday 20 October 2010 17:01:32 =JeffH wrote: > perhaps RobS can provide some rationale for this practice? Hi Jeff. Comments inline (taken from the message I sent you privately a few days ago)... > > > ALL IN ONE services.acheckamerica.com suite.agile1.com > > > www.etimeentry.com ALL IN ONE > > > > Duplicate instances of the same AVA at both ends of the DN (I'd like to > > see that go in an LDAP directory!). "ORGANIZATIONNAME domain1 domain2 ... domainN ORGANIZATIONNAME" I suspect that most (probably all) of these were issued by Comodo's CA system. Some years ago, when we first looked at the possibility of launching a "multi- domain SSL certificate" product, our testing showed that some browsers would use multiple Common Names but not multiple SAN->dNSNames. Of course, even back then the reverse was true with various other browsers. To offer maximum compatibility, we elected to give certificate applicants the option of having all of their domains encoded as both CNs and dNSNames. The Windows Certificate Viewer (for example) typically displays "Issued to: ". Since this only displays 1 CN, we figured it might confuse people when there were multiple CNs present in the certificate. Therefore, we decided to (by default) encode the Organization Name as both the first and last CN, to make sure that the Windows Certificate Viewer would actually show "Issued to: ". Here's a (perhaps out-of-date) Wiki page from another CA who seem to have done pretty much the same research we did: http://wiki.cacert.org/VhostTaskForce Note that "CN+SubjectAltNames" has the most green "Yes"es. > > > intranet.zsi.at bibliothek.intranet.zsi.at webmail.intranet.zsi.at > > > wiki.intranet.zsi.at ztools.intranet.zsi.at > > > > This contains a DN with components thrown together in more or less > > arbitrary order, again with CNs at both the start and end of the This was us too. It's a variation on the previous case. The customer elected to i) have the 2 Organization Name CNs omitted and ii) have a particular CN (intranet.zsi.at) first (i.e. encoded last) in the list. (We normally encode them in alphabetical order). > Yes, they obviously aren't backing their CA databases with an X.500-based > directory. Indeed. > I suspect hardly anyone (or even no-one) does so. > > > =JeffH > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From stpeter@stpeter.im Mon Oct 25 05:12:27 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A32FF3A69E2; Mon, 25 Oct 2010 05:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 XTZ57XTDQFJe; Mon, 25 Oct 2010 05:12:22 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7521C3A6A0E; Mon, 25 Oct 2010 05:12:14 -0700 (PDT) Received: from squire.local (dsl-179-124.dynamic-dsl.frii.net [216.17.179.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9065D40D1E; Mon, 25 Oct 2010 06:21:42 -0600 (MDT) Message-ID: <4CC5747E.4080006@stpeter.im> Date: Mon, 25 Oct 2010 06:13:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Philipp Hancke References: <4CBF3310.8060801@stpeter.im> <4CBF56A9.1090503@mail.symlynx.com> In-Reply-To: <4CBF56A9.1090503@mail.symlynx.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010200060906080708060001" Cc: certid@ietf.org, XMPP Working Group Subject: Re: [certid] [xmpp] Fwd: Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 12:12:27 -0000 This is a cryptographically signed message in MIME format. --------------ms010200060906080708060001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/20/10 2:52 PM, Philipp Hancke wrote: > There is a minor problem with that from the XMPP-s2s POV: it does not > (explicitly) cover the case where a server verifies the identity of a > peer server (see rfc3920bis 6.2.4 or the s2s section of XEP 0178 for > details). >=20 > AFAICS, the only difference is that the reference identifier is supplie= d > by the peer instead of being constructed as described in section 4.2. >=20 > Therefore, I'd propose adding the following note to the end of section = 4.1: > Note: Some application protocols such as XMPP perform the procedure > described in this section when verifiying a server identity in a > certificate presented by a TLS client. By this, and in contrast to the > procedure described in the next subsection, the reference identifier is= > supplied by the peer (TLS client). Except for this and the inverted > client-server role, the verification process remains unchanged. Thanks for the proposed text. I suggest the following tweaks: Note: In some application protocols, the procedure described in this section can be performed by an application server acting as a TLS client when verifying a server-to-server connection, not only by an application client when verifying a client-to-server (e.g, this is true of XMPP). In this case, the application server verifies the identity of the peer server that is attempting to connect and thereore the reference identifier is in essence supplied by the peer server (e.g., as triggered by a request to send a message from an associated with the peer server to an entity associated with the application service). Other than the source of the reference identifier and the inverted roles of the TLS client and TLS server, the verification process remains unchanged. /psa --------------ms010200060906080708060001 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NTEyMTM1MFowIwYJKoZIhvcNAQkEMRYEFG4jS9qYgDSjMeX7B+R4bPKDQsFSMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQBPSkbpolIEG6z/GAB1pg/FCd0APdaoZuifyD0DsNz4HkPg9xfVD361jkAK yR1tbVuSOVKomMp58Mqn+ALDiR0F1ED0CiKkeTr9erG8v62UvKjmLWgbhi5pS/sjnVWgFvNQ zpgGnfKdlXeOV/2HzRHHtwWyszzutXKz21vHg0c8RWlithnlxAyEi3ptaCn02SrxoJ4OTuJG APbwViFdDqcDW5yisCpqAjo4u6BIaB3vNveNqRWU5jKlL2zqWXZ4v/DQEC/Qrh+XApOdY/KE h1ovbHoM5YZZ1JqcAyIVJ2sv7iR4U1ACh3UNNIAUFb6/qclEQm8dltlhvUUNjTFABNHFAAAA AAAA --------------ms010200060906080708060001-- From stpeter@stpeter.im Mon Oct 25 06:43:44 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F42273A69B1; Mon, 25 Oct 2010 06:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, 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 Ea58pvSfPCGg; Mon, 25 Oct 2010 06:43:43 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0337D3A6A1B; Mon, 25 Oct 2010 06:42:29 -0700 (PDT) Received: from squire.local (dsl-179-124.dynamic-dsl.frii.net [216.17.179.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F0F6E40D1E; Mon, 25 Oct 2010 07:51:18 -0600 (MDT) Message-ID: <4CC5897C.3080600@stpeter.im> Date: Mon, 25 Oct 2010 07:43:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Philipp Hancke References: <4CBF3310.8060801@stpeter.im> <4CBF56A9.1090503@mail.symlynx.com> <4CC5747E.4080006@stpeter.im> In-Reply-To: <4CC5747E.4080006@stpeter.im> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070907080005080102010206" Cc: certid@ietf.org, XMPP Working Group Subject: Re: [certid] [xmpp] Fwd: Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 13:43:44 -0000 This is a cryptographically signed message in MIME format. --------------ms070907080005080102010206 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 10/25/10 6:13 AM, Peter Saint-Andre wrote: > On 10/20/10 2:52 PM, Philipp Hancke wrote: >> There is a minor problem with that from the XMPP-s2s POV: it does not >> (explicitly) cover the case where a server verifies the identity of a >> peer server (see rfc3920bis 6.2.4 or the s2s section of XEP 0178 for >> details). >> >> AFAICS, the only difference is that the reference identifier is suppli= ed >> by the peer instead of being constructed as described in section 4.2. >> >> Therefore, I'd propose adding the following note to the end of section= 4.1: >> Note: Some application protocols such as XMPP perform the procedure >> described in this section when verifiying a server identity in a >> certificate presented by a TLS client. By this, and in contrast to the= >> procedure described in the next subsection, the reference identifier i= s >> supplied by the peer (TLS client). Except for this and the inverted >> client-server role, the verification process remains unchanged. >=20 > Thanks for the proposed text. I suggest the following tweaks: >=20 > Note: In some application protocols, the procedure described in this= > section can be performed by an application server acting as a TLS > client when verifying a server-to-server connection, not only by an > application client when verifying a client-to-server (e.g, this is > true of XMPP). In this case, the application server verifies > the identity of the peer server that is attempting to connect and > thereore the reference identifier is in essence supplied by the > peer server (e.g., as triggered by a request to send a message from > an associated with the peer server to an entity associated with the > application service). Other than the source of the reference > identifier and the inverted roles of the TLS client and TLS server, > the verification process remains unchanged. Oops, there were some typos and missing words. That's what I get for replying to email while eating breakfast at 6 AM. Corrected text: ### Note: In some application protocols, the procedure described in this section can be performed by an application server acting as a TLS client when verifying a server-to-server connection, not only by an application client when verifying a client-to-server connection (e.g, this is true of XMPP). In this case, the application server verifies the identity of the peer server that is attempting to connect and therefore the reference identifier is in essence supplied by the peer server (e.g., as triggered by a request to send a message from an entity associated with the peer server to an entity associated with the application service). Other than the source of the reference identifier and the inverted roles of the TLS client and TLS server, the verification process remains unchanged. ### /psa --------------ms070907080005080102010206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy NTEzNDMyNFowIwYJKoZIhvcNAQkEMRYEFB2luMluZh/D/2HHFu/hMXdJ3uQgMF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQATDExqXjn73YPApBjzmICczrGaJ/bB/pL2YGc49vIpX1EmE3UO/FI8vnko te0TtR0C16bffUdoxwM7WsXjw91GesNg5zXEAs1fqDrDufQJRWl+I7iD7hdhibqX8j/wZRHR slsZ+TukDLdMe33mUlxLTMxAu8ljNiBpqY9uzQ/59/1nUs0m79BXiN6wJGImFyW7pSPHJB1t uitD8fiVrQiZabzbF//0Liwmbf3jOgs2QKS/JihwxOJSTpDrG6SMZV/Uury3fgjoq1cphqjz kiAGx2A9cZ/MXND0TkioI3+ZUKVUYDMd5dAbfmWFOjryxXSDGd6mCxZFvg7Yzi61U6rrAAAA AAAA --------------ms070907080005080102010206-- From ietf@augustcellars.com Fri Oct 29 20:41:39 2010 Return-Path: X-Original-To: certid@core3.amsl.com Delivered-To: certid@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F79F3A6767 for ; Fri, 29 Oct 2010 20:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.594 X-Spam-Level: X-Spam-Status: No, score=-1.594 tagged_above=-999 required=5 tests=[AWL=1.005, BAYES_00=-2.599] 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 qEDlQLFnfOzF for ; Fri, 29 Oct 2010 20:41:38 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by core3.amsl.com (Postfix) with ESMTP id 38AB53A63D2 for ; Fri, 29 Oct 2010 20:41:38 -0700 (PDT) Received: from TITUS (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTP id E18E36EF0C; Fri, 29 Oct 2010 20:43:33 -0700 (PDT) From: "Jim Schaad" To: "'Peter Saint-Andre'" , "'IETF cert-based identity'" References: <4CBF1A75.4010205@stpeter.im> In-Reply-To: <4CBF1A75.4010205@stpeter.im> Date: Fri, 29 Oct 2010 20:53:20 -0700 Message-ID: <001801cb77e6$03edf160$0bc9d420$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQENnyH/QQIN+7/nBPHD7DIwWmd4l5TUidnQ Subject: Re: [certid] Fwd: I-D Action:draft-saintandre-tls-server-id-check-10.txt X-BeenThere: certid@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Representation and verification of identity in certificates List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2010 03:41:39 -0000 Peter, 1. I had an email problem so probably missed the discussion, however I = do not understand the current text for the example of a delegated = domain. I would suggest text, but as I am running on I don't understand = that is not possible. Is this supposed to be some type of mapping that = says the domain X is really the domain Y? 2. In the definition of reference identifier s/optionally/optionally/ 3. In section 2.1 you have the sentence "This dimension matters most = for certificate verification." Would this be more appropriate as = s/verification/consumption/ ? The process of certificate verification = does not really care, but the name matching does. 4. In the definitions you might want to add one for "automated client" = to match "interactive client" 5. On page 20, the following text exists: For an interactive client, it is strongly encouraged that each reference identifier SHOULD be based on the source domain provided by the user and SHOULD NOT be based on a derived domain (e.g., a host name or domain name discovered through DNS resolution of the source domain). I am not clear why this is important for interactive clients and not for = automated clients. 6. In section 4.6.2 - I am disappointed that the concept of checking = that the context is either the same or similar is not also included in = this check. I think this is an important concept. Jim > -----Original Message----- > From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On = Behalf Of > Peter Saint-Andre > Sent: Wednesday, October 20, 2010 9:36 AM > To: IETF cert-based identity > Subject: [certid] Fwd: I-D = Action:draft-saintandre-tls-server-id-check-10.txt >=20 > Finally! The diff is here: >=20 > = http://tools.ietf.org/rfcdiff?url2=3Ddraft-saintandre-tls-server-id-check= -10 >=20 > -------- Original Message -------- > Subject: I-D Action:draft-saintandre-tls-server-id-check-10.txt > Date: Wed, 20 Oct 2010 09:30:02 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : Representation and Verification of Domain-Based > Application Service Identity within Internet Public Key Infrastructure = Using > X.509 (PKIX) Certificates in the Context of Transport Layer Security = (TLS) > Author(s) : P. Saint-Andre, J. Hodges > Filename : draft-saintandre-tls-server-id-check-10.txt > Pages : 46 > Date : 2010-10-20 >=20 > Many application technologies enable a secure connection between two > entities by means of Internet Public Key Infrastructure Using X.509 > (PKIX) certificates in the context of Transport Layer Security (TLS). > This document specifies best current practices for representing and = verifying > the identity of application services in such interactions. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-= 10.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the = Internet- > Draft.