Re: [keyassure] publishing the public key

[Henry Story <[e-mail]>]

[[
  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
  http://www.w3.org/2005/Incubator/webid/track/issues/39 
 
  For people on that list the thread here is
  http://www.ietf.org/mail-archive/web/keyassure/current/msg01874.html
]]
  


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

> Henry Story <[e-mail]> 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 
https://datatracker.ietf.org/doc/rfc5280/

(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

[[
4.1.2.7.  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 4.1.1.2.  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.security.spec._
import java.math.BigInteger
val keySpec = new RSAPublicKeySpec(new BigInteger("""E394D1B3CE644D809D8A85B6816E22F6C7741B9A294D2E4CB477733C16FEC0C9B346B26078944148114234393CF634A742947E264D1D22A55CF6B5E98ADACD897B9896FCDE5836008BBBC8463057F67848F5A31B41B032E4765CD546A1DD7DE3FC2423C88EAC72332AC9174E0BCA4E9FE973D90C3C622617C0CEA69B45C01CFBA90F247C26E1BCE419A251BC46287F7B00EDC34B538066CC2A285BB99B423012942768D619D261C1B668EC847E56CCF621D8B15E860FC2109317A8261F7AF894F0490703AFF323E88EAD45C4F6B8B34684D81575BF2A78AC842FD12AAE5D8EE52C9858087BE3EB8C8C7A0CA9C7ED05EBF411145E20D654A70118D586C25332A9""",16), new BigInteger("65537"))


import java.security.KeyFactory;
import java.security.interfaces._
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 ( http://pastebin.com/TEpMBJK5 )
// you will see this returns
//
// MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA45TRs85kTYCdioW2gW4i9sd0G5opTS5M
// tHdzPBb+wMmzRrJgeJRBSBFCNDk89jSnQpR+Jk0dIqVc9rXpitrNiXuYlvzeWDYAi7vIRjBX9nhI
// 9aMbQbAy5HZc1Uah3X3j/CQjyI6scjMqyRdOC8pOn+lz2Qw8YiYXwM6mm0XAHPupDyR8JuG85Bmi
// UbxGKH97AO3DS1OAZswqKFu5m0IwEpQnaNYZ0mHBtmjshH5WzPYh2LFehg/CEJMXqCYfeviU8EkH
// A6/zI+iOrUXE9rizRoTYFXW/KnishC/RKq5djuUsmFgIe+PrjIx6DKnH7QXr9BEUXiDWVKcBGNWG
// wlMyqQIDAQAB
//


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

import sun.security.util.DerValue
val der = new DerValue( rsaKey.getEncoded )
val newKey = X509Key.parse(der)

The output from the scala shell is shown in 
   http://pastebin.com/TEpMBJK5


> 
>> 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
http://bblfish.net/