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
