Dan,
On Apr 21, 2008, at 2:22 PM, Dan Wing wrote:
> During WGLC an objection was raised about R-CERTS in
> draft-ietf-sip-media-security-requirements. I currently have
> proposals for:
>
> * reverting to the R12 text
> * sticking with R-CERTS text
> * removing the text completely
>
> I would like to understand what people want this requirement to
> *mean* -- does
> it say what you think it should say? Does it miss some aspect of
> signing/certificates that is important?
DY> I think this is an important requirement in that it allows the use
of self-signed certificates. If I recall previous discussions
correctly, the major concern was that we didn't want to get in a
situation where in order to use a key management protocol all parties
were *required* to obtain certificates signed by a formal Certificate
Authority. We wanted any solution to allow the optional use of self-
signed certs for various instances where CA-signed certs might not be
appropriate or necessary.
DY> So I think the *intent* of the requirement - as I understand it -
is still important to capture. What about merging R12 and R-CERTS by
simply replacing the "CA-issued" with "3rd-party-signed", as in:
R-CERTS: If the media security key management protocol
employs certificates, it MUST be able to make use of both
self-signed and 3rd-party-signed certificates.
DY> Or is that muddying things up even more?
My 2 cents,
Dan
>
>
> -----
>
> Details:
>
> In draft-ietf-sip-media-security-requirements-00 and -01, we had:
>
> R12: The media security key management protocol MUST NOT
> require 3rd parties to sign certificates.
>
> in draft-ietf-sip-media-security-requirements-02, this was renamed
> to R-CERTS
> and also had its text change to:
>
> R-CERTS: If the media security key management protocol
> employs certificates, it MUST be able to make use of both
> self-signed and CA-issued certificates. As an alternative,
> the media security key management protocol MAY make use of
> "bare" public keys.
>
>
> Here is how some key management systems would fare with the original
> R12 text:
>
> * RFC4474 would comply -- because RFC4474 allows both self-signed
> certificates and allows CA-signed certificates (reference end of
> Step 1 of Section 6 of RFC4474). One might reasonably expect most
> deployments will use CA-signed certificates.
>
> * OpenPGP certificates (if someone were to use it for SRTP
> keying) would comply -- because R12 allows you to sign your own
> key and does not require someone else sign your key. One might
> expect most deployments would include signatures by other
> people (3rd parties).
>
> * ZRTP would comply -- because there are no 3rd party signatures
> whatsoever.
>
> * MIKEY-RSA complies -- because it allows self-signed certificates
> (reference the first bullet of Section 4.3.2 of RFC3830).
>
> * Identity-Based Encryption (if someone were to use it for SRTP
> keying) would comply -- because IBE uses 'bare' public keys.
>
>
> and with the R-CERTS text:
>
> * RFC4474 would comply (same reason as R12).
>
> * OpenPGP certificates (if someone were to use it for SRTP keying)
> would not comply -- because R-CERTS allows you to sign your own
> key, but only mentions Certificate Authorities as 3rd party
> signers; OpenPGP does not have 'certificate authorities'.
>
> * ZRTP would comply (same reason as R12).
>
> * MIKEY-RSA complies (same reason as R12).
>
> * Identity-Based Encryption (if someone were to use it for SRTP
> keying) would comply (same reason as R12).
>
> -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
--
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
