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

[Richard Barnes <rbarnes at bbn.com>]

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



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?
> 
> -----
> 
> 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 sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip
> 
> 

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip