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