>
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.
Regards,
Dan
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation [EMAIL PROTECTED]
Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com
Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com
Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free
_______________________________________________
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
