Subject: Re: [keyassure] publishing the public key

From: Peter Gutmann <[email-masked]>
Date: Sat, 19 Feb 2011 14:24:35 +1300

[Several of my posts didn't make it to the list, these are re-posts of earlier
 messages]

Paul Wouters <[email-masked]> writes:
>On Tue, 15 Feb 2011, Peter Gutmann wrote:
>>> The public key's type and raw blob will be obtained from DNSSEC, so this is
>>> no longer required to be conveyed to the client from the server via a PKIX
>>> certificate or other ASN.1 structures.
>>
>> But what format is the "type and raw blob" in?  You need some way of encoding
>> it, and if it's not the standard ASN.1 format what are you going to use?
>
>I'm not sure I understand your question.

A public key contains a number of components and options. For example for ECC
there are the basic key values p, a, b, G, n, h (or m, f, a, b, G, n, h for
binary curves), an indication of the underlying field (prime or binary), the
point format, whether point compression is used, polynomial vs. normal basis,
whether fixed domain parameters are used, and probably some other stuff I've
forgotten.  How is all this stuff communicated?

>The key would encoded in DNS, likely in a format similar to DNSKEY.

DNSKEY (RFC 3757) just specifies an opaque value labelled "public key".  If
you mean RFC 4034:

  RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
  Diffie-Hellman [DH]      n      [RFC2539]   -
  DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
  Elliptic Curve [ECC]              TBA       -
  RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY

this (a) ain't gonna cut it because it doesn't cover what's required by TLS
and (b) requires that your TLS implementation speak DNSSEC (or at least the
DNSKEY part of DNSSEC) just to get a key. I can't see TLS implementors being
too enthusiastic about this.

Peter.

---

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 10:51:11 +0100

I had received your mails Peter.  Your mail is also available in the archives.

   http://www.ietf.org/mail-archive/web/keyassure/current/msg01846.html

Ilari Liusvaara came up with a format for raw keys in what seems to be C
   
   http://www.ietf.org/mail-archive/web/keyassure/current/msg01803.html

(though I am not sure that C is progress over ASN.1 for such a specification)

My question is: what do people use now to pass public keys? I know an X509 cert
contains the public key, though I don't know if it can contain ECC keys. 
If it does then there is another simple answer: extract the part of that document
that contains both the type of the key and the details of it, and use that.

So in the XML world the xmldsig spec defines the KeyInfo element 
http://www.w3.org/TR/xmldsig-core/#sec-KeyInfo
which specified the following keys

   * http://www.w3.org/2000/09/xmldsig#DSAKeyValue
   * http://www.w3.org/2000/09/xmldsig#RSAKeyValue
   * http://www.w3.org/2000/09/xmldsig#X509Data
   * http://www.w3.org/2000/09/xmldsig#PGPData
   * http://www.w3.org/2000/09/xmldsig#SPKIData
   * http://www.w3.org/2000/09/xmldsig#MgmtData

So there one could just take the KeyInfo Element, and use that as a document format to place the
keys in. Of course one would remove X509, PGP keys, and one would have to define an xml structure for
elliptic curve keys. I am not recomending this option

So essentially there has to be a way of having a structure a bit more general than the following
that can encode all the needed keys and that is extensible

  RSAPublicKey ::= SEQUENCE {
    modulus           INTEGER,  -- n
    publicExponent    INTEGER   -- e
  }

So there does not seem to be a lack of solutions. The trick I suppose is finding the one that is the most likely to be adopted. I suppose some ASN.1 DER encoding is the one most tools are ready for.

Henry

On 19 Feb 2011, at 02:24, Peter Gutmann wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

Social Web Architect
http://bblfish.net/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 09:09:31 -0800

The problem with this approach is that it means that we are going to at best
be exercising new code paths in existing code. At worst we are going to
force people to write new code.

It is impossible to run TLS without X.509 code in the stack. Everything else
is superfluous.

This is really bikeshedding. It is not going to simplify implementation by
an iota and it is going to create yet another special case to support.

I don't think the crypto community wants to support yet another key format.
Even if that format is 'merely' a subset of an existing format.

On Sat, Feb 19, 2011 at 1:51 AM, Henry Story <[email-masked]>wrote:

> So there does not seem to be a lack of solutions. The trick I suppose is
> finding the one that is the most likely to be adopted. I suppose some ASN.1
> DER encoding is the one most tools are ready for.
>
> Henry
>

-- 
Website: http://hallambaker.com/

---

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 18:32:15 +0100

On 19 Feb 2011, at 18:09, Phillip Hallam-Baker wrote:

> The problem with this approach is that it means that we are going to at best be exercising new code paths in existing code. At worst we are going to force people to write new code.
> 
> 
> It is impossible to run TLS without X.509 code in the stack. Everything else is superfluous.
> 
> This is really bikeshedding. It is not going to simplify implementation by an iota and it is going to create yet another special case to support. 
> 
> I don't think the crypto community wants to support yet another key format. Even if that format is 'merely' a subset of an existing format.

 I don't think that is a problem. On the foaf-protocols list we were discussing not so long ago using the public key element of X.509 only. in DER format.  So that instead of writing

:me cert:publicKey [ rsa:modulus "..."; rsa:exponent "..." ]

people could write

:me cert:publicKey "SDFSDFJSRUSFZJLSDF"^^cert:derEncoded .

People using python, perl, javascript found no problem with the parsing of this. The javascript people even went so
far as to write a javascript ASN.1 parsing library.

https://github.com/digitalbazaar/forge/blob/master/js/asn1.js

I am kind of against that more because it is silly to embed an ASN.1 DER syntax inside an XML syntax. It just creates
twice the work and no real benefit (only the illusory benefit that you have 1 string, whereas in fact you then have to
parse it with some other parse to get the two numbers out of it) 
But I think that since you believe it has to be X509, then ASN.1 should be the road for you. And I think that people working
at the DNS level should have no trouble working with those tools, especially the consumers such as browser vendors.

Henry

> 
> On Sat, Feb 19, 2011 at 1:51 AM, Henry Story <[email-masked]> wrote:

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Feb 2011 10:41:50 -0800

On 2/19/11 9:09 AM, Phillip Hallam-Baker wrote:
> The problem with this approach is that it means that we are going to at
> best be exercising new code paths in existing code. At worst we are
> going to force people to write new code.

Fully agree on both. I have yet to see what I asked for early on, which 
is any text that explains how a TLS client who gets a bare key would use 
it in TLS.

If there is later a standards-track extension to TLS that handles bare 
public keys, that format can be added to TLSA at that time. It would use 
the exact same format so that clients can do exact matching without 
having to process either the key data from TLSA/DNS or the key data from 
the TLS handshake.

I'm still open to hearing *why* adding bare keys would help TLSA, but I 
would also want to see text about how the processing would go so that I 
could weigh the benefit against the cost.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 20 Feb 2011 08:46:08 +1300

Henry Story <[email-masked]> writes:

>My question is: what do people use now to pass public keys?

X.509 key bags.

>I know an X509 cert contains the public key, though I don't know if it can
>contain ECC keys.

It can contain any kind of key for any algorithm likely to be used with TLS.

>If it does then there is another simple answer: extract the part of that
>document that contains both the type of the key and the details of it, and
>use that.

In that case why not just stick with X.509?  This is bizarre, you have a
universally-agreed-on, universally-supported format, and you're proposing to
extract a subset of that requiring custom coding in each implementation to
support and use that?

Another reason to stick with X.509 as key bags is that eventually you're going
to want to put policy in the DNS ("must connect with TLS", "must use EV
certs", "must use a PFS algorithm like DH/ECDH", "cannot use non-FIPS
algorithms", and so on).  Guess what X.509v3 key bags were specifically
designed for?

The end result is that you'll end up reinventing X.509 as a container format,
only it'll be some homebrew parallel format that needs custom code to support
and endless kludging as things get bolted on that'd be automatically supported
in the X.509 key bag format.  It's reinventing the wheel, but making it square
just to be different.

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 19 Feb 2011 12:34:15 -0800

I agree with Peter here.

Folk who are bike-shedding this one need to understand that he is the person
they need to persuade to write the code.

At RSA he demonstrated a large number of issues with PKI that largely come
from it giving more options than people care to know what to do with. DNSSEC
is already more complex than X.509 was at a similar stage of deployment.

What appears to be a simpler mechanism to implement is only going to save
time and effort if it REPLACES the existing mechanism completely and
ELIMINATES the need to code for it.

Comparison to the design choices in FOAF is not very helpful since 1) FOAF
has something of a traction/deployment problem in itself and 2) use in FOAF
does not disrupt an existing deployed infrastructure.

Predicting the security implications for a design change for a security
protocol deployed for 16 years is going to be very error prone.

---

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 22:25:10 +0100

On 19 Feb 2011, at 20:46, Peter Gutmann wrote:

> X.509 key bags

Is that the same as X509? If not is there a specification one can look that up on?

> It can contain any kind of key for any algorithm likely to be used with TLS.

great! So we at least no longer have the problem of the encoding.

> extract a subset of that requiring custom coding in each implementation to

If the parsers for X509 are already written, then parsers for a subset
of X509 are already written. It's going to be easy to use the same tools.
At least I think one should not dismiss that possibility. The code to select
the subset is going to be at most a few lines.

> algorithms", and so on).  Guess what X.509v3 key bags were specifically

That is a reason for the argument to allowing the current options that enable the DNS to also send full X509 documents. Btw. I have not really looked at policy that much, can you point  me to a human readable document I can understand this part of X.509 more? (use cases and such)

> The end result is that you'll end up reinventing X.509 as a container format,

Not at all, since we are selecting a piece of it.

It would be as if you had a parser for atom <feed> documents [1] which contain <entry> elements. The someone comes along and says that they have a use case for documents containing <entry> documents only. The problem of parsing those documents is not going to be an issue, neither is the semantics of entry, at least for anyone who already has a parser for <feed>

> in the X.509 key bag format.  It's reinventing the wheel, but making it square

There is no re-inventing the wheel here at all. 

The advantage would bet that you are giving a format where you express the key (so to speak) information. So that is why initially I was asking what the benefits in terms of packets sent on the wire would be between just sending the key in this subset of X509 and sending the full X509. For sites like Google this could make an important difference. That is something that is measurable, and could let us know if there is an advantage at all of considering this. 

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.

Henry

[1] http://www.ietf.org/rfc/rfc4287.txt

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Sat, 19 Feb 2011 22:39:26 +0100

On 19 Feb 2011, at 21:34, Phillip Hallam-Baker wrote:

> I agree with Peter here.
> 
> Folk who are bike-shedding this one need to understand that he is the person they need to persuade to write the code.
> 
> At RSA he demonstrated a large number of issues with PKI that largely come from it giving more options than people care to know what to do with. DNSSEC is already more complex than X.509 was at a similar stage of deployment.

Well that is why the idea of using a subset of X509 could hit a sweet spot. It requires no new tools, but could also reduce
the complexity even further. The publication of a subset of X509 would be simpler than X509 to implement, and so reduce the
problems with it.

> What appears to be a simpler mechanism to implement is only going to save time and effort if it REPLACES the existing mechanism completely and ELIMINATES the need to code for it.
> 
> 
> Comparison to the design choices in FOAF is not very helpful since 1) FOAF has something of a traction/deployment problem in itself and 2) use in FOAF does not disrupt an existing deployed infrastructure.

There are probably a lot  more foaf files out there now than CA signed TLS signed end points now. And I think those are just going to grow.  But that was not the point of my bringing foaf into the discussion. It was just that naturally a few people we were working with thought of using a subset of X509 to solve their problem. 

> 
> Predicting the security implications for a design change for a security protocol deployed for 16 years is going to be very error prone.

Not if you use a subset of what you are already using. In fact that is why I am arguing for it. I don't like complexity. So for me in public key cryptography it is the public keys that are key [sic]. The question should be:
 
 - why not serve the minimal information needed
 - what advantage does one get by serving the full X509
 - what (dis)advantage of both
 - why not the public key rather than the signature?
 
The debate is not a either/or debate here. You already have 4 options in section 2.2 of http://tools.ietf.org/html/draft-ietf-dane-protocol-04 If it were to be an either/or, it could be between the options of  publishing the signature and the option of publishing the public key. It seems to me that the public key is a lot more useful. 

Henry

> 
> 
> On Sat, Feb 19, 2011 at 11:46 AM, Peter Gutmann <[email-masked]> wrote:

Social Web Architect
http://bblfish.net/

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 20 Feb 2011 16:01:53 +1300

Henry Story <[email-masked]> 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.

---

From: Henry Story <[email-masked]>
Date: Sun, 20 Feb 2011 14:15:37 +0100

[[
  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
]]

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

> How do you get from CertCreateContext() to turn-this-encoded-blob-into-a-

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

> ignore it at their leisure.  Putting it in a seperate RFC would make this even

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.

Social Web Architect
http://bblfish.net/

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Feb 2011 17:57:00 -0500 (EST)

On Sat, 19 Feb 2011, Phillip Hallam-Baker wrote:

> The problem with this approach is that it means that we are going to at best be exercising new code paths in existing
> code. At worst we are going to force people to write new code.
> 

The alternative is shipping a bunch of nonsense fields for eternity. If
you assume that the self signed certs will migrate to DNSSEC validation,
then that would be the vast majority of certificates out there. The
crypto community should not want that either, though I don't claim to
represent them.

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 20 Feb 2011 15:59:35 -0800

On Sun, Feb 20, 2011 at 2:57 PM, Paul Wouters <[email-masked]> wrote:

>> best be exercising new code paths in existing
>> I don't think the crypto community wants to support yet another key
>> format. Even if that format is 'merely' a subset of
>> an existing format.
>>
>

Just like the useless Edison light bulb screw fitting that has been the
standard here for over a century despite better options, the existing
standards will continue until there is a paradigm shift that cannot be
accommodated in a backwards compatible manner (e.g. halogen bulbs).

What is being discussed here is not such a paradigm shift.

There are many things in the world that are bad and worth changing. ASN.1 is
bad, but it is not one of them.

You do not make code simpler by introducing additional code paths. You only
make code simpler if you remove them. The way to make this code base simpler
is to remove the code path that you are proposing.

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 21 Feb 2011 15:42:52 +1300

>is to remove the code path that you are proposing.

Couldn't have put it better myself.  To respond to the OP, instead of guessing 
what implementers might in theory do if you bothered to ask them, why not 
actually ask them?  As a TLS implementer myself, I have absolutely zero 
interest in supporting yet another arbitrary key format (and the ensuing 
increase in complexity and attack surface), particularly one that serves no 
purpose that I've been able to identify.

Peter.