Hi Eric,
your proposal is fine with me. I just have one point I would like to
change. Your current proposal is restricted to media plane key
management protocols. I think the text you proposed holds for both
(media and signaling) so I would suggest to just state "key management
protocol" instead of "media plane key management protocol" in section
4.9
Ciao
Steffen
> -----Original Message-----
> From: Eric Rescorla [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, May 13, 2008 7:15 PM
> To: Dan York
> Cc: Dan Wing; 'Eric Rescorla'; 'IETF SIP List'; Fries,
> Steffen (CT); 'Dean Willis'
> Subject: Re: [Sip] draft-ietf-sip-media-security-requirements-05
>
> At Tue, 13 May 2008 08:38:33 -0400,
> Dan York wrote:
> >
> > >
> > Dan,
> >
> > > 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.
> >
> > Your wordsmithing is fine by me. I also liked the discussion you
> > included in section 4.9 which explains the rationale for this
> > requirement more.
> >
> > 4.9. Certificates
> >
> > The discussion in this section relates
> to R-CERTS.
> >
> > On the Internet and on some private
> networks, validating another
> > peer's certificate is often done
> through a trust anchor -- a list of
> > Certificate Authorities that are
> trusted. It can be difficult or
> > expensive for a peer to obtain these
> certificates. In all cases,
> > both parties to the call would need to
> trust the same trust anchor
> > (i.e., "certificate authority"). For
> these reasons, it is important
> > that authentication mechanisms that
> utilize trust anchors not rely
> > exclusively on such Certificate
> Authority-issued certificates, but
> > to
> > also allow self-signed certificates. By
> allowing the use of such
> > self-signed certificates, an
> out-of-band mechanism (e.g., manual
> > configuration) can be used to trust a
> peer's certificate.
>
> I was sort of OK with Dan's original text, though I probably
> would have wordsmithed it differently, but I don't agree with
> this discussion at all.
> Any certificate system can in principle be used with
> self-signed certs by doing SSH-style fingerprint exchange.
> The question is whether there is a practical deployment model
> that actually supports this.
>
>
> Consider two examples, both using TLS:
>
> - HTTPS in the majority of cases is incompatible with manual
> establishment
> of peer credentials. You connect to a lot of different Web
> servers and
> it's not practical to obtain their certificates out of band.
> - IMAP over TLS is compatible with manual establishment of
> peer credentials
> because you connect with only one or two servers and you
> already share
> a shared secret (the password) so it's at least in
> principle possible
> to record their cert fingerprint. This is also why SSH works.
>
> So, this isn't fundamentally an issue of protocol encoding
> (as Richard has observed) but rather of the context in which
> the protocol is embedded.
>
>
> So, I would rewrite this section as follows:
>
> On the Internet and on some private networks, validating another
> peer's certificate is often done through a trust anchor -- a list
> of Certificate Authorities that are trusted. It can be difficult
> or expensive for a peer to obtain these certificates. In all
> cases, both parties to the call would need to trust the same
> trust anchor (i.e., "certificate authority"). For these reasons,
> it is important that the media plane key management protocol
> offer a mechanism that allows end-users who have no prior
> association to authenticate to each other without acquiring
> credentials from a third party trust point. Note that this does
> not rule out mechanisms in which servers have certificates and
> attest to the identities of end-users.
>
> And since I'm in the writing business, I would adjust R-CERTS
> as follows:
>
> The media security key management protocol MUST NOT require
> that end-users obtain credentials (certificates or private
> keys) from a third-party trust anchor.
>
> -Ekr
>
_______________________________________________
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
