Subject: [Sip] R-CERTS in draft-ietf-sip-media-security-requirements

From: "Dan Wing" <[email-masked]>
Date: Mon, 21 Apr 2008 11:22:42 -0700

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?

-----

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Richard Barnes <[email-masked]>
Date: Mon, 21 Apr 2008 15:35:06 -0400

I am strongly in favor of removing the text completely.  It's vaguely 
worded (relying on an undefined notion of a "3rd party") -- and 
meaningless, since no extant IETF protocol (or I-D, AFAIK) violates it.
--RB