IETF Logo Mail Archive

Re: [keyassure] publishing the public key

Peter Gutmann <pgut001@cs.auckland.ac.nz> Sun, 20 February 2011 03:01 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 888913A6CBA for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 19:01:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ahbFFu7TaMgn for <keyassure@core3.amsl.com>; Sat, 19 Feb 2011 19:01:18 -0800 (PST)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by core3.amsl.com (Postfix) with ESMTP id 123213A6D85 for <keyassure@ietf.org>; Sat, 19 Feb 2011 19:01:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1298170916; x=1329706916; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20henry.story@bblfish.net,=20pgut001@cs.auckland.ac. nz|Subject:=20Re:=20[keyassure]=20publishing=20the=20publ ic=20key|Cc:=20keyassure@ietf.org|In-Reply-To:=20<EDBE4E6 4-37F2-497E-80C5-3E271B52516A@bblfish.net>|Message-Id:=20 <E1PqzYX-0001rl-3u@login01.fos.auckland.ac.nz>|Date:=20Su n,=2020=20Feb=202011=2016:01:53=20+1300; bh=dBUbUsTCeLKBA+T89xB9BSm1UWwkhOgS53cC7vN52Qo=; b=YeNKh7TYY7pcafM+SdGB9O8PsJq+8UL86tt5QdfU8n46Vn/3T0s7HfI+ kZxXCVLmmZ0qMiKAr8OVcZ03z9VcDgzBwSGNRI+2oaME5vAvMa+2ZQqbz EYCBCj0xd8pH2j87qLsBygIgQDOqVzqzzsnWNX8DziE8IWPqSIVp196pO 8=;
X-IronPort-AV: E=Sophos;i="4.62,193,1296990000"; d="scan'208";a="46943825"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Feb 2011 16:01:53 +1300
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PqzYX-0004ci-Gf; Sun, 20 Feb 2011 16:01:53 +1300
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1PqzYX-0001rl-3u; Sun, 20 Feb 2011 16:01:53 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: henry.story@bblfish.net, pgut001@cs.auckland.ac.nz
In-Reply-To: <EDBE4E64-37F2-497E-80C5-3E271B52516A@bblfish.net>
Message-Id: <E1PqzYX-0001rl-3u@login01.fos.auckland.ac.nz>
Date: Sun, 20 Feb 2011 16:01:53 +1300
Cc: keyassure@ietf.org
Subject: Re: [keyassure] publishing the public key
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Feb 2011 03:01:19 -0000

Henry Story <henry.story@bblfish.net> writes:

>Is that the same as X509? 

It *is* X.509, just used as a key bag (with optional attributes).

>The code to select the subset is going to be at most a few lines.

How do you get from CertCreateContext() to turn-this-encoded-blob-into-a-
public-key-context?

>Currently we are not asking to remove the other options. Just to see if this
>option is possible, and to work out what the advantages and disadvantages
>would be.

Well I'm OK with that, as long as it's made optional so implementers can
ignore it at their leisure.  Putting it in a seperate RFC would make this even
easier.

Peter.

v2.23.0 | Report a Bug | By Email