Hi,
thanks for the rewording Dan. The new text is fine with me.
Ciao
Steffen
> -----Original Message-----
> From: Dan Wing [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 07, 2008 3:09 AM
> To: 'Eric Rescorla'
> Cc: 'IETF SIP List'; 'Richard Barnes'; 'Dean Willis'; Fries,
> Steffen (CT)
> Subject: RE: [Sip] draft-ietf-sip-media-security-requirements-05
> Importance: High
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of
> > Eric Rescorla
> > Sent: Monday, May 05, 2008 5:01 PM
> > To: Dan Wing
> > Cc: 'IETF SIP List'
> > Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05
> >
> > At Mon, 5 May 2008 15:48:30 -0700,
> > Dan Wing wrote:
> > At Mon, 5 May 2008 15:48:30 -0700,
> > Dan Wing wrote:
> > > * R-CERTS now reads:
> > >
> > > The media security key management protocol MUST NOT
> constrain
> > > the set of trust anchors that a peer can use to validate
> > > certificates used in the protocol.
> >
> > I don't mean to be difficult, but I don't think that this actually
> > captures the relevant issue particularly well.
> >
> > One of the primary reasons why the RTPSEC work got started
> was that it
> > became clear that one could not safely assume that end-users would
> > have certificates which were verifiable by others. If we
> could assume
> > that, then life would be a lot simpler. For instance, we could have
> > ubiquitous S/MIME and use S/MIME signatures instead of RFC
> 4474. For
> > that matter, we could use DTLS-SRTP without any screwing
> around with
> > fingerprints, just based on the certificates.
> >
> > So, I don't think the requirement is that the protocol not
> constrain
> > the set of trust anchors. [Honestly, I'm not really sure what that
> > means. Does HTTPS meet this requirement?]
>
> The HTTPS protocol, that exists on the wire, does not enforce (or
> know) how the certificate is validated, of course. But if an
> HTTPS client implementation required that the TLS certificate
> had a trust anchor (that is, was signed by a CA), then that
> HTTPS client implementation would not meet the requirement.
> Of course, almost every deployed HTTPS client allows the user
> to create a whitelist of trusted certificates (Firefox,
> Safari, IE, Opera). So, almost every deployed HTTPS client's
> implementation would meet the requirement.
>
> > Without trying to wordsmith
> > it, I would say that the requirement is that the protocol be secure
> > even if the users do not have credentials attested to by
> *any* trust
> > anchor.[0] That is what the relevant distinction is between
> > self-signed and third-party certificates.
> >
> > -Ekr
> >
> > [0] Incidentally, one of Dan's messages stated that he
> believed that
> > IBE would be consistent with R-12. I suppose that might be
> technically
> > true, but I think it pretty clearly does not meet the spirit of the
> > requirement. In order to use an IBE system, the user has to get a
> > private key from the PKG. This is just as inconvenient as
> what we are
> > trying to avoid with this requirement, namely forcing the
> user to deal
> > with the CA/PKG.
>
> The wordsmithing task falls to me, I suppose.
>
> Here is another straw man, which I think captures your
> sentence above your signature and your [0] comment:
>
> R-CERTS:
>
> The media security key management protocol MUST NOT require
> using a trust anchor to validate credentials (e.g., a
> certificate) or to obtain credentials (e.g., a private key)
> used in the protocol.
>
> (The "or to obtain credentials" clause is intended to cover
> the IBE case.)
>
> -d
>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
