Subject: Re: [wpkops] Second draft charter proposal

From: Santosh Chokhani <[email-masked]>
Date: Tue, 4 Sep 2012 09:43:18 -0400

Hi Tim,

Based on my experience client authentication should be largely out of scope except for the issues such as hints list and how client selects the certificate to be presented.

Most of the other issues I see on the Server side when authenticating the client certificate are generic PK enablement issues and not specific to Web.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tim Moses
Sent: Friday, August 31, 2012 11:52 AM
To: [email-masked]
Subject: Re: [wpkops] Second draft charter proposal

All - I have no fundamental objection to expanding the scope in the ways suggested.

It's true that the original idea was to limit the scope to server-auth to Web browsers.  That's because vulnerabilities have been demonstrated and the impact can clearly be severe.  Do those conditions exist for client-auth and CalDAV?  If not, I might assign them lower priority.

On the other hand, if they impact the workload by no more than (say) 10%, why wouldn't we include them?

I think it's important to remember that increased workload must be borne not just by the editors but also by the reviewers (every subscriber to the mail-list).

All the best.  Tim.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carl Wallace
Sent: Thursday, August 30, 2012 12:31 PM
To: Jon Callas; [email-masked]
Subject: Re: [wpkops] Second draft charter proposal

On 8/30/12 12:28 PM, "Jon Callas" <[email-masked]> wrote:

>On Aug 30, 2012, at 9:18 AM, Carl Wallace wrote:
>
>>> And for issuers, it can be difficult to predict what proportion of 
>>> the user population will accept a certificate chain with certain 
>>> characteristics.  For instance, when a browser includes a nonce in 
>>> an OCSP request but the server supplies a response that does not 
>>> include the nonce, it is hard to know which browsers will accept and 
>>> which will reject the response.
>>> 
>>> 
>>> 
>> 
>> Is client authentication processing performed by web servers in scope?
>>If
>> not, explicitly push that out of scope.
>
>It would be nice if it were in scope. Client authorization is a vastly 
>under-used feature.
>
>I wouldn't want to endanger everything else over it, but if we keep 
>sweeping it under the rug, it will continue to languish.

I agree and would like to see it stay in scope as well.  

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 4 Sep 2012 12:28:41 -0400

I would like to see us 'do' something 'about' client authentication.

But I don't see much of a client PKI out there to be operated, I think
we are going to have to 'build stuff' to fix it. So I don't think its
a PKI operations issue.

I would prefer to see a separate, security area WG to look into the
client ops side. In particular I don't want to spend time trying to
work out how to automate the 'certificate lifecycle' premised on the
idea that client certs expire on an annual basis in a group where we
can't ask why the cert has to expire.

On Thu, Aug 30, 2012 at 12:31 PM, Carl Wallace
<[email-masked]> wrote:
>>>> And for issuers, it can be difficult to predict what proportion of the
>>>> user population will accept a certificate chain with certain
>>>> characteristics.  For instance, when a browser includes a nonce in an
>>>> OCSP request but the server supplies a
>>>> response that does not include the nonce, it is hard to know which
>>>> browsers will accept and which will reject the response.
>>>>
>>>>
>>>>
>>>

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

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 4 Sep 2012 10:50:26 -0600

While I agree that it needs to be addressed, I'm not sure I want to enlarge
the scope when our success will depend on our ability to handle the workload
and address and resolve the issues presented.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Phillip Hallam-Baker
Sent: Tuesday, September 04, 2012 10:29 AM
To: Carl Wallace
Cc: [email-masked]; Jon Callas
Subject: Re: [wpkops] Second draft charter proposal

But I don't see much of a client PKI out there to be operated, I think we
are going to have to 'build stuff' to fix it. So I don't think its a PKI
operations issue.

I would prefer to see a separate, security area WG to look into the client
ops side. In particular I don't want to spend time trying to work out how to
automate the 'certificate lifecycle' premised on the idea that client certs
expire on an annual basis in a group where we can't ask why the cert has to
expire.

On Thu, Aug 30, 2012 at 12:31 PM, Carl Wallace <[email-masked]>
wrote:
>>>> include the nonce, it is hard to know which browsers will accept 
>>>> and which will reject the response.
>>>>
>>>>
>>>>
>>>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 04 Sep 2012 18:57:32 +0200

> we are going to have to 'build stuff' to fix it. So I don't think its

http://www.w3.org/2012/webcrypto

---

From: Jon Callas <[email-masked]>
Date: Tue, 04 Sep 2012 15:29:31 -0400

> and address and resolve the issues presented.

I would rather push it off than have an unfocused group, but I still think it is part of "web PKI" and someone has th address it, so why not us?

If I connect to example.com, it proves to me who it is through a certificate. I want to prove to it who I am through a certificate, too. That's the two halves of web PKI and it's that latter part I would like to include, if possible. 

Jon

---

From: Jon Callas <[email-masked]>
Date: Tue, 04 Sep 2012 15:32:22 -0400

> http://www.w3.org/2012/webcrypto

This isn't the same thing. JOSE and all of that are doing crypto, and they are doing it on the web, but it isn't web PKI, either server side nor client side. 

Jon

---

From: "Ben Wilson" <[email-masked]>
Date: Tue, 4 Sep 2012 13:43:08 -0600

I'm fine addressing it, I just don't want to add things without realizing
that there may be indirect impacts on quality and focus.  I like client auth
--  I just want to see the distinct subtasks laid out coherently so that the
work can be kept straight.

-----Original Message-----
From: Jon Callas [mailto:[email-masked]] 
Sent: Tuesday, September 04, 2012 1:30 PM
To: [email-masked]
Cc: Phillip Hallam-Baker; Carl Wallace; [email-masked]
Subject: Re: [wpkops] Second draft charter proposal

On Sep 4, 2012, at 12:50, Ben Wilson <[email-masked]> wrote:

> While I agree that it needs to be addressed, I'm not sure I want to 
> enlarge the scope when our success will depend on our ability to 
> handle the workload and address and resolve the issues presented.

I would rather push it off than have an unfocused group, but I still think
it is part of "web PKI" and someone has th address it, so why not us?

If I connect to example.com, it proves to me who it is through a
certificate. I want to prove to it who I am through a certificate, too.
That's the two halves of web PKI and it's that latter part I would like to
include, if possible. 

Jon

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 04 Sep 2012 21:51:31 +0200

> This isn't the same thing. JOSE and all of that are doing crypto, and they are doing it on the web, but it isn't web PKI, either server side nor client side.

Jon, in Korea there are 25M active certificates for consumers, in Sweden there are 5M.
These schemes are based on proprietary client software.
One of the targets of WebCrypto is to get rid of this software.

Here is a private proposal on how this could be done:

   http://webpki.org/papers/PKI/pki-webcrypto.pdf

Anders

---

From: Jon Callas <[email-masked]>
Date: Wed, 05 Sep 2012 09:05:42 -0400

>   http://webpki.org/papers/PKI/pki-webcrypto.pdf

Anders,

This is a laudable goal, and indeed something worth solving. It is also something that JOSE addresses. It still isn't what we are talking about here. 

Repeating my use case, Alice connects to example.com with TLS. The host example.com authenticates to her with its certificate and she authenticates to example.com with hers. At that point, there is a mutually-authenticated TLS connection between them. This is a fine place to start using the webcrypto protocols over that TLS connection for use cases including those in that paper.

I hope that what we would do in this working group would be to document edge conditions that the usual PKI documents don't address in using a client certs. I don't expect it to be much more than a few paragraphs, myself, but I'd be willing to lose it for the larger goal. 

Jon

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 05 Sep 2012 15:19:37 +0200

On 2012-09-05 15:05, Jon Callas wrote:
> This is a laudable goal, and indeed something worth solving.
> It is also something that JOSE addresses. It still isn't what we are talking about here.

Pardon my ignorance but I'm not sure then what you mean with client-side PKI.

> 
> Repeating my use case, Alice connects to example.com with TLS.
> The host example.com authenticates to her with its certificate
> and she authenticates to example.com with hers. At that point,
> there is a mutually-authenticated TLS connection between them.
> This is a fine place to start using the webcrypto protocols
> over that TLS connection for use cases including those in that paper.

I don't think this applies to the payment example I outlined.
In such scenarios you authenticate the server but not the client.
The client rather signs (authorizes) a request.  The request
may even be rerouted behind the curtain to another party
(like your bank), although it (for the user) looks like you
actually pay directly to the merchant.

> 
> I hope that what we would do in this working group would be to 
> document edge conditions that the usual PKI documents don't address
> in using a client certs.

I have no idea what this could be so I look forward to any kind of documentation.
I'm personally trying to get the basics going because currently it doesn't work well at all.

Anders

I don't expect it to be much more than a few paragraphs, myself, but I'd be willing to lose it for the larger goal.