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