Re: [keyassure] publishing the public key

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 <pgut001@cs.auckland.ac.nz> wrote:
> Henry Story <henry.story@bblfish.net> 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.
> _______________________________________________
> keyassure mailing list
> keyassure@ietf.org
> https://www.ietf.org/mailman/listinfo/keyassure
> 
> 
> 
> -- 
> Website: http://hallambaker.com/
> 

Social Web Architect
http://bblfish.net/