Re: [Sipping] SIP certificate management (RFC 6072) and SIP outbound
Cullen Jennings <fluffy@cisco.com> Mon, 10 October 2011 23:32 UTC
Return-Path: <fluffy@cisco.com>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7971D21F8513 for <sipping@ietfa.amsl.com>; Mon, 10 Oct 2011 16:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSDquVT-GNzv for <sipping@ietfa.amsl.com>; Mon, 10 Oct 2011 16:32:57 -0700 (PDT)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 42F2321F8AE6 for <sipping@ietf.org>; Mon, 10 Oct 2011 16:32:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=1159; q=dns/txt; s=iport; t=1318289575; x=1319499175; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=8j+5wbgB+oSVPvuDbsturREAx5/AtbbqX/kUu2QRJDY=; b=jrkseZV4DLU/S7Mv38Cvq+DEnlU2fjNGuBjvksxEgBEeCMJ+LgBN9zQl 63z2D2qgfLVkIcSociRSNISfLb0Nkt7hIHaDurV3VxzxUUy/N86oQTr6f 4oOQUueH7Hi6BVo5DfU6GIipFckgrhw71jgujp9VudvJeD5AdfEyZZjL2 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAGqAk06rRDoJ/2dsb2JhbABDqCSBBYFTAQEBAwESASc/BQsLRlcGNYdcmysBnjSGYmEEh32LeoUpjEg
X-IronPort-AV: E=Sophos;i="4.68,519,1312156800"; d="scan'208";a="7076930"
Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 10 Oct 2011 23:32:55 +0000
Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9ANWsJM020243; Mon, 10 Oct 2011 23:32:54 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <6CAE043E-9B12-48A9-B9D4-969284B7470C@edvina.net>
Date: Mon, 10 Oct 2011 17:32:54 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC523C79-2A0D-435C-B24B-E1164DB06E9A@cisco.com>
References: <6CAE043E-9B12-48A9-B9D4-969284B7470C@edvina.net>
To: "Olle E. Johansson" <oej@edvina.net>
X-Mailer: Apple Mail (2.1084)
Cc: sipping@ietf.org
Subject: Re: [Sipping] SIP certificate management (RFC 6072) and SIP outbound
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2011 23:32:57 -0000
On Oct 10, 2011, at 2:05 PM, Olle E. Johansson wrote: > After reading RFC 6072 I can't help to wonder how this works with an outbound proxy configured in the UA. > > For instance, using SIP Outbound we have two proxys that we keep an active flow to. RFC 6072 says that > the UA is required to have a direct connection to the certificate service in order to publish a key and certificate. > This is in order to be able to examine the servers certificate. > > Does this mean that a UA that follows RFC 6072 should override the pre-defined route in the UA and thus > also ignore the SIP outbound mechanism for this transaction? Those outbound guys and 6072 guys should really talk to each other :-) Yes, the implementation I have seen are just skipping the outbound proxy for managing their own credentials. The alternative is to use an outbound server that you trust at the same level as your credential server. I don't like this as much because even thought they are likely managed by the same domain, the credential server is probably a bit more carefully managed with less going on with it.
- [Sipping] SIP certificate management (RFC 6072) a… Olle E. Johansson
- Re: [Sipping] SIP certificate management (RFC 607… Cullen Jennings