IETF Logo Mail Archive

Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt

Laurence Lundblade <llundbla@qti.qualcomm.com> Tue, 18 April 2017 02:40 UTC

Return-Path: <llundbla@qti.qualcomm.com>
X-Original-To: cose@ietfa.amsl.com
Delivered-To: cose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84051129411 for <cose@ietfa.amsl.com>; Mon, 17 Apr 2017 19:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=qti.qualcomm.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNJthZHhwCJd for <cose@ietfa.amsl.com>; Mon, 17 Apr 2017 19:40:24 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C3B712940C for <cose@ietf.org>; Mon, 17 Apr 2017 19:40:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1492483224; x=1524019224; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Gj8bzUUUUIroDsFWaXXHa8gSElpwjcMh5j+odOfyoTw=; b=UUqViOKe3K4INKZyZfVBmzAGCPPtfD2tUhw5xYexzzk1e4Q9QeSmWbhd Wg1lmztB5RUyEzEp8r5eMTEIwMeFnlSq06siiQKhd2sQsSZ9gF+nZR/8p y3+m3WAE83rfr/shs+3TPPlY0dIkIeKmUvu4lFvF+qIZS1wkZY6jcqCzL 4=;
X-IronPort-AV: E=Sophos;i="5.37,217,1488873600"; d="scan'208,217";a="374909512"
Received: from unknown (HELO Ironmsg04-L.qualcomm.com) ([10.53.140.111]) by wolverine02.qualcomm.com with ESMTP; 17 Apr 2017 19:40:23 -0700
X-IronPort-AV: E=McAfee;i="5800,7501,8501"; a="1330923054"
X-MGA-submission: MDE9Rmq+t65zk8rzlNmq7wNqqmhIt9pHPaPJA9uhiPYhSez3HgBAw9uVM/kLRq2G9whCvB9vuTo1yBKFjyvv2uMuWtS+zM6UmmupiGRfHiH4uYDl/XA76IOCKGfJjEbNFdzAUyECC3maDKNeb06nl2+J
Received: from nasanexm01e.na.qualcomm.com ([10.85.0.31]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Apr 2017 19:40:22 -0700
Received: from NASANEXM01B.na.qualcomm.com (10.85.0.82) by NASANEXM01E.na.qualcomm.com (10.85.0.31) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 17 Apr 2017 19:40:22 -0700
Received: from NASANEXM01B.na.qualcomm.com ([10.85.0.82]) by NASANEXM01B.na.qualcomm.com ([10.85.0.82]) with mapi id 15.00.1178.000; Mon, 17 Apr 2017 19:40:22 -0700
From: Laurence Lundblade <llundbla@qti.qualcomm.com>
To: Jim Schaad <ietf@augustcellars.com>
CC: cose <cose@ietf.org>
Thread-Topic: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt
Thread-Index: AQHSUE9n8gqDeU8N0UWR0TVip3PpF6HLgYAAgAAli4CAAAfrgA==
Date: Tue, 18 Apr 2017 02:40:21 +0000
Message-ID: <7FD2726F-42F8-47DF-92F5-7C399D80A662@qti.qualcomm.com>
References: <147987163959.30322.14158962529156430503.idtracker@ietfa.amsl.com> <004901d24546$8e76bfe0$ab643fa0$@augustcellars.com> <CAF2hCbZK4+mSHTqvZQnzFD+7F8PDkP0q3JNFYp=dOMRkE+Vh=w@mail.gmail.com> <9CE238FE-6AF0-458D-A1C7-B790870323D3@qti.qualcomm.com> <06e701d24f77$8d438280$a7ca8780$@augustcellars.com> <CAF2hCbbdp=mW5yfKvWoF-Tm53-CdVPQe7Xx-+TPpJwjsiMzofQ@mail.gmail.com> <BB0F527A-E061-427D-AA0B-C5CDDE4B9A76@qti.qualcomm.com> <000d01d2b7e9$2b0a6450$811f2cf0$@augustcellars.com>
In-Reply-To: <000d01d2b7e9$2b0a6450$811f2cf0$@augustcellars.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3273)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.80.80.8]
Content-Type: multipart/alternative; boundary="_000_7FD2726F42F847DF92F57C399D80A662qtiqualcommcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/cose/fAu2ZLLdSbm8PcqFc7N8m9v2i8s>
Subject: Re: [COSE] New Version Notification for draft-schaad-cose-x509-00.txt
X-BeenThere: cose@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: CBOR Object Signing and Encryption <cose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cose>, <mailto:cose-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cose/>
List-Post: <mailto:cose@ietf.org>
List-Help: <mailto:cose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cose>, <mailto:cose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2017 02:40:25 -0000

Hi Jim,

Thanks for the quick comment.

On Apr 17, 2017, at 7:11 PM, Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:

The problem w/ trying to define a single way to do SKI is that different Cas are going to do it in different ways and that is always a problem.

If you are doing a certificate enrollment protocol, it is always possible to return some information back to the end point that it can use or the same purpose.  It could either return a Key Id that the client is supposed to use or it could return a hash of the certificate as we have a way to identify that as well.

I’m sorry I can’t share details, but I can assure you that this is not possible in the use case I have in mind.

I think that leaves us either with the CA and users of this scheme having to assume a particular way to compute SKI or inventing some typing scheme for SKIs.

Maybe that ends the conversation…



One of the problems for certificate based people on just using the SKI for identifying the certificate is to make sure that there are not more than one certificate in the world.  If multiple certificates exist (see attacker), then it is always possible that a certificate with a different identity or set of associated attributes can be obtained when you do the indirection.  Use the hash of the certificates (even a truncated one) makes this a much harder problem to solve.

This seems like a problem when you trust a lot of roots, but not so much of a problem when trusting just one or two proprietary roots.  Is that right?

Also, any pointer on what happened with RFC 4387 to look up and fetch certs via HTTP?

Thanks again,

LL

v2.23.0 | Report a Bug | By Email