Re: [stir] draft-asveren-stir-p-charge-info

Christer Holmberg <> Tue, 29 May 2018 08:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B967A12DB71 for <>; Tue, 29 May 2018 01:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5DaI77lvX5vd for <>; Tue, 29 May 2018 01:04:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3EF712E868 for <>; Tue, 29 May 2018 01:04:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1527581067; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dopnNOBO76zGKIJQxekE09EPdMCFZgNqitsuIKw5wqM=; b=Pn9KPZ/vikJPU+B5hF3Llww0kbf0X1OXMe6c1zXR0B0YmjcNT+IcRTeVU1Iz23Kz X6tFNvYed/G8Uaq4opBCo6IA+BD9X+uh3ylwPeYaaMcWu0q4zfQSyygk9K9y0QMa Xh50P6klOB29HHhIBM9atVW7oN4NArTkUYa/8J4Lldc=;
X-AuditID: c1b4fb30-e2dff70000004da5-b4-5b0d098b8ce9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C0.AD.19877.B890D0B5; Tue, 29 May 2018 10:04:27 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0382.000; Tue, 29 May 2018 10:04:26 +0200
From: Christer Holmberg <>
To: "Asveren, Tolga" <>, "" <>
Thread-Topic: [stir] draft-asveren-stir-p-charge-info
Thread-Index: AQHT5y2kgFuajFQnO0ah0J0LULLxoaRFiU5wgAANrwCAAPPbAA==
Date: Tue, 29 May 2018 08:04:26 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D732E1553099Cchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPIsWRmVeSWpSXmKPExsUyM2J7oG43J2+0wYEmEYvla7cxWaxf/o3d gcljyZKfTB575kxiDGCK4rJJSc3JLEst0rdL4MrY9n4mY8GnsIq3Z26xNDD+8e5i5OSQEDCR 2H3kGnMXIxeHkMARRomf9w8wQjiLGSU+PNzD0sXIwcEmYCHR/U8bpEFEwFOipfcAE4gtDNR8 /fp5Noi4qcTKSxdYIGwnieebdoDZLAKqEu3dm9lBbF4Ba4kna/+C1QsJXGGU6JpsC2JzCsRK vL96hBXEZhQQk/h+ag3YfGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf2D1ogJ6EhtO3GYHOVNC QEni9gYniNYEidMfzkCtFZQ4OfMJywRGkVlIps5CUjYLSRlE3EDi/bn5zBC2tsSyha+hbH2J jV/OMkLY1hIbjzYyIatZwMixilG0OLU4KTfdyEgvtSgzubg4P08vL7VkEyMw2g5u+W2wg/Hl c8dDjAIcjEo8vOtZeKOFWBPLiitzDzFKcDArifCW7uWJFuJNSaysSi3Kjy8qzUktPsQozcGi JM5r4bc5SkggPbEkNTs1tSC1CCbLxMEp1cAoMcFZ5ruewYrn8qKr2FmPPd/fYvFa6V/pi6zj hyeaLar5KVXb9tngeMzKSHXLpGZmjgPzzM8oZUwRNrvV6nuqwUpq+TrB8G71g8wcsRxzvX/L Lbs39W/lt7u35XPTy9253J9vjdzQwCnj9tHN+K/b/5eHND2/fPKr9pNiPHb3YGHmm7dyUxyU WIozEg21mIuKEwFkX5b6sgIAAA==
Archived-At: <>
Subject: Re: [stir] draft-asveren-stir-p-charge-info
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 29 May 2018 08:04:33 -0000


Q1: As the purpose of draft-york-p-charge-info is document existing implementations and usage of the PCI header field, the first question is whether we should define “enhancements” and new usages of the PCI header field?
[TOLGA] draft-asveren-stir-p-charge-info does not add new functionality for P-Charge-Info per se. It merely add verification capability for it.

True, but it is not documenting existing implementations anymore.

Q2: You should describe in what kind of environments this is needed.
[TOLGA]Noted and will add it in the next version -among other things-.

Q3: As draft-york-p-charge-info is to be published as an Informational RFC, should draft-asveren-stir-p-charge-info also be Informational? A PASSporT extension is “Specification Required”, so I assume an Informational RFC qualifies.
[TOLGA]thanks for the feedback. I don’t have a problem with that and would follow what is required from procedures perspective and will change it to “Informational”.

I was also going to comment on the fact that you don’t reference the york draft, but Keith already brought that up :)

Q4: The text in Section 4.3 says:

   "An entity dropping P-Charge-Info MUST drop the corresponding Identity

   header with "ppt" parameter value of "pci”."

        First, I assume you mean “an entity supporting the pci PASSporT”?

        Second, entities that only support the PCI header field, but not the pci PASSporT, will not remove the corresponding Identity header field. I think you need some text about that.
 [TOLGA] I think this depends on what is meant by “supporting pci PASSPortT”. An entity can still remove it if it is aware of “pci” but does not support it in terms of adding/verifying pci Identity. OTOH, an entity completely unaware of “pci” wouldn’t be able to do so.

Correct – that is the use-case I had in mind.