Re: [keyassure] publishing the public key

Henry Story <> Sun, 20 February 2011 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 161253A6FAB for <>; Sun, 20 Feb 2011 05:15:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iqAkuLF8vV5d for <>; Sun, 20 Feb 2011 05:15:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 3EEBF3A6B62 for <>; Sun, 20 Feb 2011 05:15:02 -0800 (PST)
Received: by fxm15 with SMTP id 15so1621466fxm.31 for <>; Sun, 20 Feb 2011 05:15:40 -0800 (PST)
Received: by with SMTP id k6mr469747faj.46.1298207740420; Sun, 20 Feb 2011 05:15:40 -0800 (PST)
Received: from bblfish.home ( []) by with ESMTPS id a6sm925263fak.1.2011. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Feb 2011 05:15:39 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Henry Story <>
In-Reply-To: <>
Date: Sun, 20 Feb 2011 14:15:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.1082)
Cc: WebID Incubator Group WG <>
Subject: Re: [keyassure] publishing the public key
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Feb 2011 13:15:04 -0000

  I am CCing this to the WebID XG Group because it is also relevant there
  to ISSUE-39: "Simplify how public keys are expressed"
  which is discussing something very similar to this issue 
  For people on that list the thread here is

On 20 Feb 2011, at 04:01, Peter Gutmann wrote:

> Henry Story <> writes:
>> Is that the same as X509? 
> It *is* X.509, just used as a key bag (with optional attributes).

A bag with only one key though. Sounds more like a singleton.
Just reading RFC5280, I don't see the option of putting more than one key in there

(Though I suppose extensions could be designed for that, though to what purpose?...)

Anyway here is how we Dane define the public key. Exactly as in rfc5280

SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

Then one just does as they do and point people to more rfcs

[[  Subject Public Key Info

   This field is used to carry the public key and identify the algorithm
   with which the key is used (e.g., RSA, DSA, or Diffie-Hellman).  The
   algorithm is identified using the AlgorithmIdentifier structure
   specified in Section  The object identifiers for the
   supported algorithms and the methods for encoding the public key
   materials (public key and parameters) are specified in [RFC3279],
   [RFC4055], and [RFC4491].

>> 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?

Hey, that's a clever way to get free programming time from people: Taunt them that they can't do something :-) And you get the added pleasure of forcing me to learn ASN.1, which I have been trying to avoid... 

Note how decoding the key is three lines of code.

So here it goes in Scala (requires Sun JVM).

// create an RSA Key

import java.math.BigInteger
val keySpec = new RSAPublicKeySpec(new BigInteger("""E394D1B3CE644D809D8A85B6816E22F6C7741B9A294D2E4CB477733C16FEC0C9B346B26078944148114234393CF634A742947E264D1D22A55CF6B5E98ADACD897B9896FCDE5836008BBBC8463057F67848F5A31B41B032E4765CD546A1DD7DE3FC2423C88EAC72332AC9174E0BCA4E9FE973D90C3C622617C0CEA69B45C01CFBA90F247C26E1BCE419A251BC46287F7B00EDC34B538066CC2A285BB99B423012942768D619D261C1B668EC847E56CCF621D8B15E860FC2109317A8261F7AF894F0490703AFF323E88EAD45C4F6B8B34684D81575BF2A78AC842FD12AAE5D8EE52C9858087BE3EB8C8C7A0CA9C7ED05EBF411145E20D654A70118D586C25332A9""",16), new BigInteger("65537"))

val keyFactory = KeyFactory.getInstance("RSA")
val rsaKey = keyFactory.generatePublic(keySpec).asInstanceOf[RSAPublicKey]

// Base64 encode it, ready for publication 

import sun.misc.BASE64Encoder
new BASE64Encoder().encode( rsaKey.getEncoded )

// In pastebin ( )
// you will see this returns
// tHdzPBb+wMmzRrJgeJRBSBFCNDk89jSnQpR+Jk0dIqVc9rXpitrNiXuYlvzeWDYAi7vIRjBX9nhI
// 9aMbQbAy5HZc1Uah3X3j/CQjyI6scjMqyRdOC8pOn+lz2Qw8YiYXwM6mm0XAHPupDyR8JuG85Bmi
// UbxGKH97AO3DS1OAZswqKFu5m0IwEpQnaNYZ0mHBtmjshH5WzPYh2LFehg/CEJMXqCYfeviU8EkH
// A6/zI+iOrUXE9rizRoTYFXW/KnishC/RKq5djuUsmFgIe+PrjIx6DKnH7QXr9BEUXiDWVKcBGNWG

// Decode the key, which could have been found in DNSsec

val der = new DerValue( rsaKey.getEncoded )
val newKey = X509Key.parse(der)

The output from the scala shell is shown in

>> 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.

Now I think that the argument that this is so difficult has been shown to be wrong, I think we can perhaps push the discussion further on this. The reasons for or against this here won't be the same as on the WebID XG, but it should be instructive none the less.

> Peter.

Social Web Architect