Subject: Re: [dane] Call for Adoption: draft-hoffman-dane-smime.

From: Warren Kumari <[email-masked]>
Date: Fri, 21 Sep 2012 13:27:29 -0400

On Sep 10, 2012, at 5:25 PM, Warren Kumari <[email-masked]> wrote:

> Dear WG,
> 
> This draft has already revived some comment (and has been revised to incorporate / address those),  so I'm assuming that there will be sufficient interest to adopt, but for the form of the thing:
> 
> This starts a call for adoption of draft-hoffman-dane-smime. 
> Please provide feedback as to if you would like this draft adopted by Sept 17th, 2012.

We have discussed this, and see sufficient interest for adopting this draft -- would the authors please re-submit as draft-dane-?

W

> 
> W
> 
> -- 
> Never criticize a man till you've walked a mile in his shoes.  Then if he didn't like what you've said, he's a mile away and barefoot. 
> 
> 
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Sep 2012 15:37:22 +0200

In general, I support the idea of what this document is trying to do.  But there are a couple of problems with their concrete approach.  Without delving into a full review…  

-- The algorithm for domain names is really insufficient.  For example, I have the email address [email-masked] -- how do the dots get encoded?  I realize that the DNS wire format allows labels to have dots, but good luck making most libraries make that query.

-- I don't really see why we need a new RR type here, beyond the cognitive dissonance caused by the three letters "TLS".

So I guess that's a vote in general favor, but maybe another rev wouldn't hurt.

--Richard

--  
Richard Barnes
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Friday, September 21, 2012 at 7:27 PM, Warren Kumari wrote:

>  
> On Sep 10, 2012, at 5:25 PM, Warren Kumari <[email-masked] (mailto:[email-masked])> wrote:
>  
> > Dear WG,
> >  
> _______________________________________________
> dane mailing list
> [email-masked] (mailto:[email-masked])
> https://www.ietf.org/mailman/listinfo/dane
>  
>

---

From: Miek Gieben <[email-masked]>
Date: Mon, 24 Sep 2012 15:49:25 +0200

[ Quoting <[email-masked]> in "Re: [dane] Call for Adoption: draft..." ]
> In general, I support the idea of what this document is trying to do.  But
> there are a couple of problems with their concrete approach.  Without delving
> into a full review…
> 
> -- The algorithm for domain names is really insufficient.  For example, I have
> the email address [email-masked] -- how do the dots get
> encoded?  I realize that the DNS wire format allows labels to have dots, but
> good luck making most libraries make that query.

Huh? Reading from section 3: (http://tools.ietf.org/html/draft-hoffman-dane-smime-04)

Design note: Encoding the user name with Base32 allows local parts
that have characters that would prevent their use in domain names.
For example, a period (".") is a valid character in a local part, but
would wreak havoc in a domain name.  Similarly, [RFC6530] allows non-
ASCII characters in local parts, and encoding a local part with non-
ASCII characters with Base32 renders the name usable in the DNS.

> -- I don't really see why we need a new RR type here, beyond the cognitive
> dissonance caused by the three letters "TLS".

new RRs are cheap. Why not get one?

grtz Miek

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Sep 2012 16:17:15 +0200

On Monday, September 24, 2012 at 3:49 PM, Miek Gieben wrote:
> [ Quoting <[email-masked] (mailto:[email-masked])> in "Re: [dane] Call for Adoption: draft..." ]
> > the email address [email-masked] (mailto:[email-masked]) -- how do the dots get

Thanks.  That's what I get for replying to email under the influence of jet lag.   
  
> new RRs are cheap. Why not get one?
Why *would* you?  The cert/chain matching semantics are the same, the only difference is how you get the cert/chain (S/MIME vs. TLS).   

New RRs are not *that* cheap.  Yes, servers and resolvers usually do let you provision arbitrary RR types by number, but that's not nearly as nice as having a real syntax, which takes time to develop and deploy.  If you've got TLSA and you just need people to look for it in a different place, why bother going to the effort of making everyone support a new type?

--Richard

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 24 Sep 2012 14:26:08 +0000

> New RRs are not *that* cheap.  Yes, servers and resolvers usually do let you provision arbitrary RR types by number, but that's not nearly as nice as having a real syntax, which takes time to devel…

My thoughts exactly.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

---

From: Miek Gieben <[email-masked]>
Date: Mon, 24 Sep 2012 16:27:32 +0200

> New RRs are not *that* cheap.  Yes, servers and resolvers usually do let you
> provision arbitrary RR types by number, but that's not nearly as nice as having
> a real syntax, which takes time to develop and deploy.  If you've got TLSA and
> you just need people to look for it in a different place, why bother going to
> the effort of making everyone support a new type?

Fair enough. Looking back in the -00 there is even:

2.2.  Format of the Resource Record

   [[ This will be the same as for TLSA because there is no reason for
   the two to diverge.  Lots of text lifted from the TLSA document. ]]

Which would further proof your point about reusing TLSA. 

But what about other SSL-like protocols (if/when they are defined for DANE
use). Should they also re-use TLSA or always use a prefix label? It would
be nice to get some kind of constency, either they *all* use TLSA or they
*all* use a prefix label.

 Regards,

-- 
    Miek Gieben                                                   http://miek.nl

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Sep 2012 16:39:24 +0200

> *all* use a prefix label.

There's a saying that goes, "We'll cross that bridge when we come to it." :)

Do you have an example of such a protocol?

--Richard

---

From: Miek Gieben <[email-masked]>
Date: Mon, 24 Sep 2012 16:43:59 +0200

> Do you have an example of such a protocol?

uhm... ftps?

 Regards,

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Sep 2012 16:52:05 +0200

FTPS is FTP over TLS :)  

Yeah, it does STARTTLS instead of jumping straight in, but it's still TLS. 

Even supposing there is an example, I don't really see the conflict.  The existence of a TLSA record under _port._protocol.example.com doesn't necessarily make any statements about what protocol is running on the indicated port.  RFC 6698 says what you do *if* you use TLS, but it doesn't rule out using it for some other protocol.  So if your favorite security protocol uses X.509 certificates to authenticate domain names, you can still use it.  

There is a risk of swapping out protocols, I guess, if an attacker can, say, run a TLS service with a matching cert on the same port.  But that doesn't jump out at me as a terribly likely or terribly damaging scenario.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 24 Sep 2012 11:02:27 -0400 (EDT)

> -- I don't really see why we need a new RR type here, beyond the cognitive dissonance caused by the three letters "TLS".

What _port._protocol would one store the SMIME information under?

If only we had decided not to use protoport prefixing....

Now we could say, store it _like_ the TLSA record at _smimecert. But
technically speaking, that is no longer a TLSA record, which
uses _port._protocol prefixing.

We'll get more of these type of records, we might as well allocate
a new RR for this one too.

Paul

---

From: Richard Barnes <[email-masked]>
Date: Mon, 24 Sep 2012 17:05:56 +0200

Oh, I'm totally not objecting to the lhs._smimecert.rhs syntax for this use case.  That makes a lot of sense, not least because S/MIME isn't a transport-layer service.  

I was just saying that in general, I don't really see a need for RR types other than TLSA -- especially because protocols can define their own mechanisms for finding TLSA records.

---

From: James Cloos <[email-masked]>
Date: Mon, 24 Sep 2012 12:38:55 -0400

>>>>> "PW" == Paul Wouters <[email-masked]> writes:

PW> If only we had decided not to use protoport prefixing....

What does that have to do with anything?  :/

An RR is defined by its wire format.  A TLSA RR is still a TLSA RR no
matter where it happens to be in the DNS.

Just like any other RR.  Eg:

     foo.example.org in ptr bar

is still a PTR RR.  No matter how unlikely it should be that anyone
might dig(1) it.

It occurs to me that what we really need is a spec for how to find *any*
tls cert association to a label which looks like an email address.  Ie,
has a right-hand-part which looks like -- and can been looked up like --
a hostname, a left-hand-part which is contrained only by lenght and an
ascii '@' separating the two.  This covers all of the typical client
certs, whether for interacting with a TLS server, email, code-signing
or anything else which might use email-like labeling.

An smime-specific draft could then reference the more general spec.

We'd need to specify something more general than _smimecert.

And it shouldn't have 'client' in the name, either.  There is no reason
to presume that a foo@bar label implies the concept of 'client'.

Maybe '_at'?  That would make my primary email address look like:

      mnwg633t._at.jhcloos.com 

Nice, generic, and suitable for all such usage.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Sep 2012 07:48:38 +1000

In message <[email-masked]>, Richard Barnes writes:
> 
> In general, I support the idea of what this document is trying to do.  Bu=
> t there are a couple of problems with their concrete approach.  Without d=
> elving into a full review=E2=80=A6 =20
> 
> -- The algorithm for domain names is really insufficient.  =46or example,=
>  I have the email address ceci.nest.pas.une.adresse=40gmail.com -- how do=
>  the dots get encoded=3F  I realize that the DNS wire format allows label=
> s to have dots, but good luck making most libraries make that query.

	The standard presentation format is

	ceci\.nest\.pas\.une\.adresse.gmail.com

	and yes most tools/libraries that handle domain names will handle
	this fine.  You can also encode the period as "\046".  There may be
	some broken tools that take 'LHS@RHS' and turn it into 'LHS.RHS'
	without escaping the periods but this really isn't hard to get
	correct.  This is also a 1/4 century old encoding so there is no
	excuse for any application to get this wrong.

% dig 'ceci\.nest\.pas\.une\046adresse.gmail.com'

; <<>> DiG 9.9.2rc1 <<>> ceci\.nest\.pas\.une\046adresse.gmail.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6886
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ceci\.nest\.pas\.une\.adresse.gmail.com. IN A

;; AUTHORITY SECTION:
gmail.com.		60	IN	SOA	ns1.google.com. dns-admin.google.com. 1498358 21600 3600 1209600 300

;; Query time: 690 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 25 07:41:24 2012
;; MSG SIZE  rcvd: 121

% 

> -- I don't really see why we need a new RR type here, beyond the cognitiv=
> e dissonance caused by the three letters =22TLS=22.
> 
> So I guess that's a vote in general favor, but maybe another rev wouldn't=
>  hurt.
> 
> --Richard
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Tue, 25 Sep 2012 07:55:13 +1000

> is still a PTR RR.  No matter how unlikely it should be that anyone

Well a PTR record is a record that points to another domain name
but is not follow when looked up unlike a CNAME.  It was defined
for use anywhere in the DNS not just in the IN-ADDR.ARPA tree. So
while your conclusion is correct your argument is invalid.

Mark

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 09:21:49 +0200

Ref: http://tools.ietf.org/html/draft-hoffman-dane-smime-04

> We have discussed this, and see sufficient interest for adopting this draft -- would the authors please re-submit as draft-dane-?

On the whole, my view is that associating a public key to a user is better done by WebID http://webid.info/  ( see spec http://webid.info/spec/ ). Putting that information in the DNS misses out on a lot of other information you would like to have about a user, is difficult to read, write, and on the whole is very cumbersome. The reason for putting public keys of servers in the DNS is that servers tend not to change that much, their tend to not be that many services per domain, etc...

There are proposals of using the WebID public keys for MIME on the WebID community group.

Henry

> [email-masked]

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 14:26:47 +0200

On 25 Sep 2012, at 13:54, Kingsley Idehen <[email-masked]> wrote:

> On 9/25/12 3:21 AM, Henry Story wrote:
> Henry,
> S/MIME and WebID work together very well. That's something we've long implemented. Notice the certificate used to sign this mail :-)
> 
> To conclude, WebID is another option with finer granularity and more distributed control (no DNS admin access privileges required, just own a profile document) re., mail sender identity verification.

It may be interesting to know from the DANE working group, what they think would need to be done to make the application of WebID to S/MIME something more widely known about. Currently the WebID spec ( http://webid.info/spec ) illustrates how one can use a WebID in a client certificate to authenticate with TLS on any server. Perhaps the WebID working group should put some documents forward on how this can be used for S/MIME? Or perhaps an RFC would be more useful for that?
I don't think we have any formal document on that yet.

  Henry

> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen	
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Sep 2012 07:09:13 -0700

WebID is not in the charter for this WG. If you want to discuss S/MIME and WebID, you are free to do so elsewhere, of course. There is no need for you to Cc this WG on that work.

--Paul Hoffman

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 16:11:40 +0200

> WebID is not in the charter for this WG. If you want to discuss S/MIME and WebID, you are free to do so elsewhere, of course. There is no need for you to Cc this WG on that work.

Neither I suppose is TLS, or MIME btw, or many other standards that are discussed on this list. But knowing that they exist has always been important to IETF practice. It's called: not re-inventing the wheel. But I see you have a problem with that. Sorry to have hurt your feelings.

Henry

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Sep 2012 07:19:08 -0700

On Sep 25, 2012, at 7:11 AM, Henry Story <[email-masked]> wrote:

> Neither I suppose is TLS, or MIME btw, or many other standards that are discussed on this list.

TLS and MIME are IETF standards. WebID is not yet a standard from any organization, I believe. Notice the difference?

> But knowing that they exist has always been important to IETF practice.

There are a zillion pre-standards efforts on the Internet; we don't need to discuss them all in a WG that is about DANE.

> It's called: not re-inventing the wheel.

WebID is completely orthogonal to DANE, or will be when it becomes standardized. Yes, you can pour anything into the WebID container. That doesn't mean that no other work needs to be done in the IETF.

> But I see you have a problem with that.

No, you see I have a problem with you trying to legitimize WebID in every possible venue in the IETF even though you have failed to get support elsewhere. Note the difference?

> Sorry to have hurt your feelings.

You are mistaking "hurt feelings" for "please don't waste our time here; feel free to work on it on your own". Note the difference?

--Paul Hoffman

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 16:44:59 +0200

> TLS and MIME are IETF standards. WebID is not yet a standard from any organization, I believe. Notice the difference?

Ah I see, if it were a standard you'd be able to discuss it? But if it is not, then you can't conceive of it... 

Now notice that your new proposal - draft-hoffman-dane-smime - is also just a proposal. 

And it  may have  disadvantage over another proposal that we could make just as easily. That proposal - based on WebID - would also be using DANE to gain strength. So I don't see the difference. If we can make proposals on this list for non DANE for server auth proposals then clearly the proposal that WebID constitutes or could constitute with a bit of imagination, would be something to take into consideration.

so difference = 0

> There are a zillion pre-standards efforts on the Internet; we don't need to discuss them all in a WG that is about DANE.

But this working group was about DANE, the project that has finished. You now want to essentially continue with the momentum to propose a standard which is only tangentially related to why people formed the DANE group.

But I see you'd rather deflect the discussion from that area, than address the points.
Anyway, let's stop this sill fighting and look at the issues.

> WebID is completely orthogonal to DANE, or will be when it becomes standardized. Yes, you can pour anything into the WebID container. That doesn't mean that no other work needs to be done in the IE…

I think the interesting thing to work out is in what way this is orthogonal.

What I don't understand yet looking at draft-hoffman-dane-smime,  is what key is going to be placed in DNS. Is it the signing key? The key that will sign the certificates? If so that could indeed be worthwhile putting in DNS. ( Though one could just as easily put that in http space ). If it is to put the client certificates themselves in DNS, then that seems much less of a good idea.

> No, you see I have a problem with you trying to legitimize WebID in every possible venue in the IETF even though you have failed to get support elsewhere. Note the difference?

You are putting a draft forward! Not a final spec.

> You are mistaking "hurt feelings" for "please don't waste our time here; feel free to work on it on your own". Note the difference?

Yes, I notice that your are mixing your role of chair with role of proposer of a spec.

Social Web Architect
http://bblfish.net/

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Sep 2012 10:45:50 -0400

Henry,

> Neither I suppose is TLS, or MIME btw, or many other standards that are discussed on this list. But knowing that they exist has always been important to IETF practice. It's called: not re-inventing…
If you were to read the DANE charter 
(https://datatracker.ietf.org/wg/dane/charter/)
you would see that TLS is cited 5 times, so your supposition above is 
wrong with regard to
its first assertion.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Sep 2012 16:00:38 +0100

> What I don't understand yet looking at draft-hoffman-dane-smime,  is what key is going to be placed in DNS. Is it the signing key? The key that will sign the certificates? If so that could indeed b…

Its pretty clear it could be either of those, though I have to say the
I-D doesn't really work properly in this respect.

It inherits the Certificate Usage field from 6698 - but 6698
references TLS and TLS servers and things like that. I fear the I-D
really needs to redefine the usages in an S/MIME context.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Sep 2012 16:01:21 +0100

Oh, also, 6.1 is incorrectly titled :-)

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 17:07:47 +0200

On 25 Sep 2012, at 16:45, Stephen Kent <[email-masked]> wrote:

> If you were to read the DANE charter (https://datatracker.ietf.org/wg/dane/charter/)
> you would see that TLS is cited 5 times, so your supposition above is wrong with regard to
> its first assertion.

Thanks. But not MIME - So the point holds well enough :-)

Anyway, the webid spec

    http://www.w3.org/2005/Incubator/webid/spec/

also is very clearly tied to TLS, and would benefit a lot from DANE being deployed. So my interest in DANE is not a side issue. The strongest pushback against WebID ( and so using client certificates ) is the cost of server certificates for most players. ( the next strongest is the inability to logout from all but Firefox browsers )

In fact my interest in DANE can be traced back to a discussion I had with Dan Kaminsky at Hackers at Random  (HAR) 3 years ago, where I quickly gave him an overview of WebID ( At the time foaf+ssl) ). This was before the creation of the DANE group. The protocols are very similar logically. 

That is why it would be worth discussing things and seeing how these protocols can work together. And perhaps there is even some interesting way for the MIME proposal to work out nicely.

Henry

Social Web Architect
http://bblfish.net/

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Sep 2012 08:09:25 -0700

> I-D doesn't really work properly in this respect.

Can you say more? I'm not seeing why the signing or encrypting key would be different, but I could be missing something obvious.

> really needs to redefine the usages in an S/MIME context.

Why? Nothing in RFC 6698 says that the certificate or bare-ish key are only for signing. In fact, signing/encrypting isn't mentioned at all.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Sep 2012 08:12:49 -0700

> Oh, also, 6.1 is incorrectly titled :-)

As announced the other day, there is now a WG document, draft-ietf-dane-smime. In that document, Section 5.1 is indeed incorrectly titled. But if you were reading the other threads on this list, you would see that maybe that section was just presciently titled. :-)

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 25 Sep 2012 17:20:21 +0200

<chair>
Ok, this conversation is becoming unnecessarily combative. Emotions are running high, and  I would appreciate participants watching their tone.
 
DANE is not finished, we have agreed to work on "How to do DANE with $foo" documents (the chairs have been remiss in not providing an updated charter for consideration that reflects this…)

Before discussing WebID *at all* I would want to discuss this all with our W3C liaison to avoid any cross SDO friction...

</chair>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 25 Sep 2012 11:22:10 -0400

Henry,

> But this working group was about DANE, the project that has finished. You now want to essentially continue with the momentum to propose a standard which is only tangentially related to why people f…
DANE is seen as a basis for using public key info published via the DNS 
to bind public keys
to DNS names, as discussed at the BoF that preceded the formation of 
this WG. The WG was chartered to deal with TLS first, to provide focus. 
The intent is to allow the WG to use the same basic mechanism to provide
public keys to other security protocols. So, your statement above, is 
not correct, both in terms of stating that the project is finished, and 
in terms of why the WG was formed.

I don't recall seeing you at that BoF; were you present?

Steve

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 17:34:12 +0200

On 25 Sep 2012, at 17:22, Stephen Kent <[email-masked]> wrote:

> DANE is seen as a basis for using public key info published via the DNS to bind public keys
> to DNS names, as discussed at the BoF that preceded the formation of this WG. The WG was chartered to deal with TLS first, to provide focus. The intent is to allow the WG to use the same basic mechanism to provide
> public keys to other security protocols. So, your statement above, is not correct, both in terms of stating that the project is finished, and in terms of why the WG was formed.

I don't have problems with this. I was just reacting to claim that one could not bring up any outside work relating to the idea of binding public keys to users using DNS. 

> I don't recall seeing you at that BoF; were you present?

I was present in Paris, not in the recent IETF meeting. 

In any case this is more a question of understanding how things can work together. Sorry if I come in a bit late into the discussion. But there is no need to get so defensive about the draft-hoffman.

Henry

Social Web Architect
http://bblfish.net/

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Sep 2012 16:41:28 +0100

> Why? Nothing in RFC 6698 says that the certificate or bare-ish key are only for signing. In fact, signing/encrypting isn't mentioned at all.

Not even by me!

But what is mentioned is, e.g.

 "Certificate usage 0 is used to specify a CA certificate, or
      the public key of such a certificate, that MUST be found in any of
      the PKIX certification paths for the end entity certificate given
      by the server in TLS. "

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Sep 2012 16:45:41 +0100

On 25 September 2012 16:07, Henry Story <[email-masked]> wrote:
> also is very clearly tied to TLS, and would benefit a lot from DANE being deployed. So my interest in DANE is not a side issue. The strongest pushback against WebID ( and so using client certificates ) is the cost of server certificates for most players.

You mean people who aren't using HTTPS to secure logins care about WebID?

> ( the next strongest is the inability to logout from all but Firefox browsers )

Am I really the only one who cares about usability?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 25 Sep 2012 08:55:11 -0700

>      the PKIX certification paths for the end entity certificate given

Ahhh, good point. We will definitely deal with that in our document. It appears more subtly in a few other places in 6698 as well.

--Paul Hoffman

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 18:06:06 +0200

> You mean people who aren't using HTTPS to secure logins care about WebID?

People who are not using HTTPS to secure logins won't have very secure logins (even passwords require protection). I am speaking about pushback from people who are serious about security (not counting the TOR type super security folks - but I will show that WebID works there too). 

> Am I really the only one who cares about usability?

Firefox usability (of client certs) sucks. All the others are pretty good, and could easily be made better by a little work from the browser vendors. I demonstrate that very clearly in the video on http://webid.info/ . Now why browser vendors like Firefox don't do the few weeks work to get useability working is beyond me. I think it is partly because they don't understand how useable they could make client certificates with WebID. 

Henry

Social Web Architect
http://bblfish.net/

---

From: Ben Laurie <[email-masked]>
Date: Tue, 25 Sep 2012 17:12:06 +0100

> Firefox usability (of client certs) sucks. All the others are pretty good, and could easily be made better by a little work from the browser vendors. I demonstrate that very clearly in the video on…

Sigh. Why do I have to go over this every time? Usability in the
browser is only part of the problem, the rest are things like moving
between machines, dealing with revocation, migrating existing accounts
and so on.

---

From: Henry Story <[email-masked]>
Date: Tue, 25 Sep 2012 18:32:33 +0200

On 25 Sep 2012, at 18:12, Ben Laurie <[email-masked]> wrote:

> Sigh. Why do I have to go over this every time?

I really don't know. I keep answering your questions precisely. Perhaps you are asking them rhetorically to help me the difficult bits to new audiences? :-)

> Usability in the

But that is exactly what WebID makes simple:
  - moving between machines: 
     + create different certificates on each machine ( use a one time passwords to log in if you want high security)
      here is a video that shows this: http://www.youtube.com/watch?v=S4dlMTZhUDc
    ( + use crypto keys if you wanted to be seriously secure )
  - dealing with revocation is easy: remove the public key from the WebID profile
   you can see how easy it is to do this on this live server https://my-profile.eu/
   (that's a one click event)
  - migrating existing accounts: you have HTTP redirects for that
 
I think the reason people never consider 1. is that they keep thinking of certificates as things you use to log into only one web site. So of course if that is what it were for, then having a certificate to login AND a password would be weird. But our position is the opposite: the purpose of a certificate is to login to any web site you wish to - usually not your home server.

Ok, so now someone is going to barge in and say this is off topic, probably just in time to avoid you having to answer the above points :-)
   But I hope those who are open to new ideas will see that there is something odd in how there is a simple working solution to a serious problem that is making the headlines every week, and how slow it is to get these ideas to move along - even amongst IETF members who have everything to gain from this working out.

   Henry

Social Web Architect
http://bblfish.net/

---

From: Richard Barnes <[email-masked]>
Date: Tue, 25 Sep 2012 18:33:03 +0200

On Tuesday, September 25, 2012 at 6:12 PM, Ben Laurie wrote:
> On 25 September 2012 17:06, Henry Story <[email-masked] (mailto:[email-masked])> wrote:
> >  
> > On 25 Sep 2012, at 17:45, Ben Laurie <[email-masked] (mailto:[email-masked])> wrote:
> >  
> > > On 25 September 2012 16:07, Henry Story <[email-masked] (mailto:[email-masked])> wrote:
> > > >  
> > > > On 25 Sep 2012, at 16:45, Stephen Kent <[email-masked] (mailto:[email-masked])> wrote:
> > > >  
> > > > > Henry,
> > > > >  

… none of which are germane to DANE.

--Richard

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 28 Sep 2012 09:22:53 +0200

> But that is exactly what WebID makes simple:
[...snip...]

With my chair hat on, I would prefer you to stop promoting unrelated technology unless you prove it's somehow related to work in this working group.  To say the truth I have seen too many emails in this WG to be reading about what WebID does and what doesn't, I just don't care (here).  Either make some clear the connection to our charter or please stop and let us focus on the work which _can_ be done in this WG.

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Henry Story <[email-masked]>
Date: Fri, 28 Sep 2012 10:34:14 +0200

> With my chair hat on, I would prefer you to stop promoting unrelated technology unless you prove it's somehow related to work in this working group.  To say the truth I have seen too many emails in…

???

I don't think I have been posting anything here for the past few days.
The discussion has moved on the the WebID Community group in the mean time:

http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html

Anyway, I am very keen on DANE being adopted widely. It is a very important
standard. The work we are doing would be hugely enhanced by it. As I said
it is likely that we work done here to use DANE for Mime could be combined 
with WebID to go even further.

Sincerely,

	Henry Story

Social Web Architect
http://bblfish.net/

---

From: Henry Story <[email-masked]>
Date: Fri, 28 Sep 2012 12:05:51 +0200

Just a last note, relevant to draf-hoffman-dane-smime-04 [1] and how it could work
with WebID. I think this is on topic for the IETF group: After all this is a 
"Call for adoption", and I am willing to adopt it. Here is how I came to that
conclusion.

 I have worked out how to get my mail signed with my WebID certificate -
it was pretty easy when I was explained how to do it in Apple Mail.

I went to keychain, and selected my certificate ( created using 
https://my-profile.eu/ ), right clicked on it and selected "New Identity Preference".

Those of you that have a client that shows the certificate - if the ietf passes that information
on - should see that the mail was correctly signed but that your client was not
able to verify the message signature: Apple mail does not know the certificate 
authority webid.fcns.eu, and why should it? Apple Mail has a yellow tab that says:
"Unable to verify message signature". I can then choose to accept that certificate
as representing me.

It would therefore be easy to write a plugin for Mail to do the following whenever a mail 
is signed by an unknown CA, but has a WebID in the SAN field:
  - do an HTTP GET on the URL
  - verify that the WebID listed in the profile document declares the public 
    key of the user as one of the user's public keys
    ( as specified by the webid spec https://webid.info/spec/ )

That would allow it then to use personal information listed in the WebID profile
to fill in my address book info, including for example a picture which it could
then show in the e-mail reader for mnemonic purposes [2]. 

Still that leaves an open problem that the IETF spec under discussion [1] will 
help with. WebID by itself could be used to check the social network of people I 
know to see if they refer to this WebID. But it would not help for knowing if
the e-mail was indeed really mine. The e-mail client could use WebFinger [3]
(another IETF spec) to go from the e-mail to the WebID. That would be one method
of verification. But WebFinger has the problem I think for the moment that it
does not necessarily go through https to do the verification, and so could be open
to a man in the middle attack.

So the draft-spec in question could be very useful by specifying in DNSSEC a 
signing key for certificates that guarantee that it was one the e-mail service
stands behind. Ie: it would have to be a guarantee that any certificate signed with that
key is one that only that user has access to. 

Still. This leaves the problem that the e-mail address itself would need to
appear in the certificate too. (which mine does not have at present! Oops!)

So it does indeed look like these two protocols are complimentary and can
work with each other - indeed may need each other. 

Given that what could WebID provide in addition to draft-hoffman-dane-smime?
I think the following:
 1. A way to easily verify that they certificate is still valid.
   If I were to loose my certificate, or think it had been copied, 
   I could just go to my profile and delete the public key associated with that
   certificate from the profile.
 2. As stated earlier it can be a way to add information flexibly to the
   certificate - a link to my social network, to my photos, to my bog,
   which would not require one to change the certificate each time one changed
   that information: the webid places information on the web, instead of placing
   it in a certificate.

Good. Given that this is a call for adoption, I would be willing to adopt this,
and even implement this in the social network I am building. That is if I have
understood the intent of draft-hoffman-dane-smime correctly.

Sincerely,

	Henry Story

[1] http://tools.ietf.org/html/draft-hoffman-dane-smime-04
[2] http://bblfish.net/blog/page9.html#2005/08/26/01-50-23-870
[3] http://tools.ietf.org/html/draft-jones-appsawg-webfinger-06

Social Web Architect
http://bblfish.net/