[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] R-CERTS in draft-ietf-sip-media-security-requirements
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 From sip-bounces at ietf.org Fri May 2 02:46:03 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 4300D3A6A65;
Fri, 2 May 2008 02:46:03 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id CA9D63A6A65
for <sip at core3.amsl.com>; Fri, 2 May 2008 02:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id mavnB5eER7sW for <sip at core3.amsl.com>;
Fri, 2 May 2008 02:46:01 -0700 (PDT)
Received: from voxeo.com (mmail.voxeo.com [66.193.54.208])
by core3.amsl.com (Postfix) with ESMTP id 53B083A6AA4
for <sip at ietf.org>; Fri, 2 May 2008 02:46:00 -0700 (PDT)
Received: from pc-00144.lodestar2.dyndns.org (account dyork [75.68.245.43]
verified) by voxeo.com (CommuniGate Pro SMTP 5.1.14)
with ESMTPSA id 30498951; Fri, 02 May 2008 09:46:02 +0000
Message-Id: <DDD632E2-1EE2-4023-98AD-20A02BF673C7 at voxeo.com>
From: Dan York <dyork at voxeo.com>
To: Dan Wing <dwing at cisco.com>
In-Reply-To: <036701c8a3dc$b0779a20$c2f0200a at cisco.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Fri, 2 May 2008 05:46:00 -0400
References: <036701c8a3dc$b0779a20$c2f0200a at cisco.com>
X-Mailer: Apple Mail (2.919.2)
Cc: 'SIP IETF' <sip at ietf.org>
Subject: Re: [Sip] R-CERTS in draft-ietf-sip-media-security-requirements
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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 renawas 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
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation dyork at voxeo.com
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
med
> 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
--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO Voxeo Corporation dyork at voxeo.com
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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip