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

RE: Plan for moving forward



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
> >>>
> >>>
> >