[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Plan for moving forward
Apologies. I had another email in my head and I wrote a shorter version (since Eric asked I have sent some emails to people asking for their recollection of the history, just in case I don't have my facts straight).
Yes, apparently for non-DRM purposes there were attempts to propose the use of client certificates with and even without PKIs (I have not looked at the relevant contributions so please treat this information as such; some of the discussions may have happened in offline discussions. People socialize contributions with other companies to see if they can build support) and I am told nothing came of it. 

thanks,
Lakshminath

On 6/12/2007 2:04 PM, Dan Wing wrote:

Your email was not at all clear, so careful re-reading does not add clarity.
Specifically, when you wrote:
For other purposes, people tell me that there were attempts in the past and they went no where (I haven't seen them and so I don't know the story for sure). 

did you mean:
For other [non-DRM] purposes, ... there were attempts ... [to have certificates on endpoints?] and they went no where. 

-d




-----Original Message-----
From: Lakshminath Dondeti [mailto:ldondeti@xxxxxxxxxxxx] Sent: Tuesday, June 12, 2007 1:29 PM 
To: Dan Wing
Cc: 'Eric Rescorla'; 'Matt Lepinski'; ietf-rtpsec@xxxxxxx
Subject: Re: Plan for moving forward

Dan
Of course I understand that. Please read my note closely :) . I was only referring to PKI in the context of DRM. 

Lakshminath

On 6/12/2007 1:26 PM, Dan Wing wrote:

I don't understand your reference to PKI.
As was explained at length -- I thought -- in Prague, 
DTLS-SRTP does not
require (nor recommend) that the endpoint's certificate 
(used for DTLS-SRTP)
be made available in any kind of certificate store ("PKI"), 
anywhere, by
anybody. Taken to an extreme, One Might Say that a new 
certificate could be
created by the endpoints for every DTLS-SRTP call, if the 
endpoint was

interested in doing such a thing.

-d


-----Original Message-----
From: owner-ietf-rtpsec@xxxxxxxxxxxx [mailto:owner-ietf-rtpsec@xxxxxxxxxxxx] On Behalf Of Lakshminath Dondeti 
Sent: Tuesday, June 12, 2007 12:48 PM
To: Eric Rescorla
Cc: Matt Lepinski; ietf-rtpsec@xxxxxxx
Subject: Re: Plan for moving forward


Eric,
I have double checked with people about where things are
in 3GPP and
3GPP2 and since you care to know the details, it is a somewhat complex story (actually not that complex). If DRM is involved, there are client certs, PKI and everything (although in case of broadcast TV, the story is different, the mobile operators may be trying to do away with PKIs in that context). But, clearly there is someone to pay for it so to speak; content business is a value-add.
For other purposes, people tell me that there were attempts in the past and they went no where (I haven't seen them and so I don't
know the
story for sure). Someone could try to make a proposal and build consensus now; the burden then is on the merits of the
proposal. It 
doesn't hurt too much is not an incentive.
There are folks on this list who also contribute to PP and PP2. If you disagree with my notes above, please do let us know. 

regards,
Lakshminath

On 6/7/2007 12:04 PM, Eric Rescorla wrote:

At Thu, 07 Jun 2007 11:26:44 -0700,
Lakshminath Dondeti wrote:
Thanks Matt. I know of cases where skipping the
self-signed cert on the
UAC side would be considered necessary. Broadly
speaking whereas
verifying server-side certs as in case of https is
alright, client-side 
certs, self-signed or not, are not really viable at the moment.

Can you provide more support for this claim?

The problems with client auth in HTTPS are almost entirely due
to user interface, but in the of DTLS-SRTP, they client auth
is hidden under the covers of the implementation and so this
is not an issue.

-Ekr