Re: [keyassure] publishing the public key

[Henry Story <[e-mail]>]

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

> Henry Story <[e-mail]> writes:
> 
>> My question is: what do people use now to pass public keys?
> 
> X.509 key bags

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

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

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

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

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.

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

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>

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

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


> 
> Peter.

Social Web Architect
http://bblfish.net/