IETF Logo Mail Archive

Re: [TLS] AD review of draft-ietf-tls-oob-pubkey

Bert Greevenbosch <Bert.Greevenbosch@huawei.com> Mon, 22 April 2013 01:23 UTC

Return-Path: <Bert.Greevenbosch@huawei.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC6F21F875C for <tls@ietfa.amsl.com>; Sun, 21 Apr 2013 18:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riVbuNqDgztE for <tls@ietfa.amsl.com>; Sun, 21 Apr 2013 18:23:39 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31BDD21F87B7 for <tls@ietf.org>; Sun, 21 Apr 2013 18:23:37 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASB10658; Mon, 22 Apr 2013 01:23:33 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Apr 2013 02:23:09 +0100
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 22 Apr 2013 02:23:31 +0100
Received: from szxeml558-mbx.china.huawei.com ([169.254.7.35]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.007; Mon, 22 Apr 2013 09:23:25 +0800
From: Bert Greevenbosch <Bert.Greevenbosch@huawei.com>
To: Sean Turner <turners@ieca.com>, "tls@ietf.org" <tls@ietf.org>, "draft-ietf-tls-oob-pubkey@tools.ietf.org" <draft-ietf-tls-oob-pubkey@tools.ietf.org>
Thread-Topic: [TLS] AD review of draft-ietf-tls-oob-pubkey
Thread-Index: AQHOOqugRs5hBntoEky0lAT8pzuh/ZjhbddA
Date: Mon, 22 Apr 2013 01:23:25 +0000
Message-ID: <46A1DF3F04371240B504290A071B4DB63D715C65@szxeml558-mbx.china.huawei.com>
References: <516D5ADE.3050506@ieca.com>
In-Reply-To: <516D5ADE.3050506@ieca.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.162.63]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [TLS] AD review of draft-ietf-tls-oob-pubkey
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Apr 2013 01:23:40 -0000

Hi Sean, all,

<quote>
13) How are we supposed to check whether key is still considered "good"? 
  If you can't that might be okay, but you need to mention that there's 
no mechanism to support this yet or that that also needs to be done 
out-of-band.
</quote>

That indeed is a problem. I have made a first attempt at solving this through the following draft:
http://datatracker.ietf.org/doc/draft-greevenbosch-tls-ocsp-lite/

The draft should not be confused with the Lightweight OCSP Profile from RFC 5019. I guess a new name is needed.

Also the draft is quite simple, it just asks a server about the revocation status of the public key. The current solution has scalability issues, so it would certainly need some work to get that right.

The raw public key was designed to remove the processing burden of a full X.509 certificate, making it easy to use in constrained environments. (CoAP refers to it.) I think revocation status checking should be similarly simple for the receiving entity.

Best regards,
Bert

v2.23.0 | Report a Bug | By Email