Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt

From: Martin Rex <[email-masked]>
Date: Tue, 2 Aug 2011 22:10:07 +0200 (MEST)

Nikos Mavrogiannopoulos wrote:
> 
> The other goal of yours of sending raw public keys might as
> well be solved by defining a new certificate type RAW in the
> certificateType registry defined in RFC6091 and send anything you like
> in the "Certificate" message. You don't need WG consensus to do that.
> But do you really have a use case that makes all that effort
> worthwhile? Why would others be interested into implementing
> the RAW keys you are proposing?

I find the idea of extending rfc6091 with a new certificate type
for raw keys more appealing that a completely new TLS extension.

I also prefer the server key to part of the full TLS handshake, so that
the situation "client doesn't trust server key" or "client expected
different server key" can be reliably distinguished from other reasons
of a Finished message verification failure.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Aug 2011 00:01:02 -0400 (EDT)

> for raw keys more appealing that a completely new TLS extension.

The TLS client still needs a way to convey this to the server, so that
there is a migration path from full CA bundle to public key. That is,
the client needs to be able to ask for "public key only" certificate type.
So I believe we would still need a new TLS extension, but not a new TLS
message type.

> of a Finished message verification failure.

I see no problems with that.

Paul

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 03 Aug 2011 08:12:19 +0200

> So I believe we would still need a new TLS extension, but not a new TLS

And doesn't RFC6091 define the extension?

---

From: Paul Wouters <[email-masked]>
Date: Wed, 3 Aug 2011 11:14:45 -0400 (EDT)

> And doesn't RFC6091 define the extension?

Ah yes, it does.

I would hope that the TLS WG would see enough of an interest to make a standard
track extension though. 6091 is an Informational. Could the draft be rerwitten to
use the 6091 cert type extension and still become a standards track document?

Paul

---

From: Martin Rex <[email-masked]>
Date: Wed, 3 Aug 2011 20:59:47 +0200 (MEST)

Paul Wouters wrote:
> > Paul Wouters wrote:
> > > Martin Rex wrote:
> I would hope that the TLS WG would see enough of an interest to make
> a standard track extension though.  6091 is an Informational.  Could
> the draft be rerwitten to use the 6091 cert type extension and still
> become a standards track document?

Huh?  Why is that?  "Informational" or "Experimental" is just fine!

Weren't you complaining that your primary motiviator for this
extension is to enable a TLS implementation without X.509?

Personally, I would not consider a TLS implementation "generally useful"
that has zero support for X.509 (not even X.509v1) (this is about
implementations, not consumers!), but I'm pretty confident that
TLS implementations without your extension likely continue
to be "generally useful".  So personally, I consider Informational
or Experimental adequate for this proposal at the current time.

It will always remain possible to submit a revised document for
standards track in case that this technology attracts widespread
adoption among implementors and consumers of the technology.

PGP is a well-established alternative to X.509 and has been in active
use for EMail and for signing software archives in Linux Distributions,
and I don't see a problem with 6091 being Informational, either.

-Martin