[stir] AD evaluation: draft-ietf-stir-passport-09

Alissa Cooper <alissa@cooperw.in> Tue, 18 October 2016 21:27 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65784129889 for <stir@ietfa.amsl.com>; Tue, 18 Oct 2016 14:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=WNOfNLzn; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=Cp8QUxmw
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiBzoD5ZK-rT for <stir@ietfa.amsl.com>; Tue, 18 Oct 2016 14:27:58 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED506129865 for <stir@ietf.org>; Tue, 18 Oct 2016 14:27:57 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 623A4206DC for <stir@ietf.org>; Tue, 18 Oct 2016 17:27:57 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 18 Oct 2016 17:27:57 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=hDY J6fqhsHh51fjG2eAhj7I/YUw=; b=WNOfNLznaVT9JQYy2zfLkKH9f8bJpYOcPux FYFhhYQvV+VI/Q1jlP190qn6ii/iy6WVarQuy9YirBftei8tU3jWwt0Jy4vtKJR3 GxC9U9Gg1mKMyf5T5aScLdEZ4WmONcVayRSf4zBKCtmbGO7oTz2rgKr/vuS7zZ/N BpHDP2fk=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=hDYJ6fqhsHh51fjG2eAhj7I/YUw=; b=Cp8QU xmwhkg8JglHSvMpwPihqRpWsc5hwv5UX02t5H4N3dp+CNP0ioOI2piTyfwt2O5Pr j2RaPDJPxHSiGLBSYok8w2O5+cmqtJv4e0Lmz+fyH6krNnmx/G43ht3VOqJGNMS/ gUzAXsUxNYSsKsI+81i8Y0LUP7w4sHlgZo57yE=
X-Sasl-enc: ha4WPsqNg17Ya7JeRwsq/zteLq7g9IcefsOPpUe6W+bd 1476826076
Received: from [10.24.82.175] (unknown [128.107.241.185]) by mail.messagingengine.com (Postfix) with ESMTPA id C4E44CC081 for <stir@ietf.org>; Tue, 18 Oct 2016 17:27:56 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Message-Id: <821D2CC3-4FCD-42B5-9D84-AEA9D7CD8943@cooperw.in>
Date: Tue, 18 Oct 2016 17:27:55 -0400
To: IETF STIR Mail List <stir@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/lEnCBRNKZHa3h_YtVKkfoTkgON0>
Subject: [stir] AD evaluation: draft-ietf-stir-passport-09
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Oct 2016 21:27:59 -0000

I have re-reviewed this document in preparation for IETF LC. I believe it is ready for LC and will issue the request for it shortly.

Below are some suggested clarifications that should be incorporated or otherwise addressed together with any last call comments.

= Section 3 =

OLD 
PASSporT specifically uses this token format and defines claims that convey the identity of the origination and destination of personal communications.  The originating identity, the primary value asserted in a PASSporT object represents the identity of the calling party or the initiator of a personal communications session.  The signer of a PASSporT object may or may not correspond to the origination identity.  For a given application's use or using protocol of PASSporT the creation of the PASSporT object is performed by an entity that is authoritative to assert the callers identity.  This authority is represented by the certificate credentials and the signature and PASSporT object is created and initiated to the destination(s) at the applications choice of authoritative point(s) in the network.  For example, the PASSporT object could be created at a device that has authenticated with a user, or at a network entity with an authenticated trust relationship with that device and it's user.  Destination identities represent the intended destination of the personal communications, i.e. the identity(s) being called by the caller.  The destination point(s) determined by the application need to have the capability to verify the PASSporT token and the digital signature.  The PASSporT associated certificate is used to validate the authority of the originating signer, generally via a certificate chain to the trust anchor for that application.

NEW 
PASSporT specifically uses this token format and defines claims that convey the identity of the origination and destination of personal communications.  The originating identity -- the primary value asserted in a PASSporT object -- represents the identity of the calling party or the initiator of a personal communications session.  The signer of a PASSporT object may or may not correspond to the origination identity.  For a given application's or protocol's use of PASSporT, the creation of the PASSporT object is performed by an entity that is authoritative to assert the caller's identity.  This authority is represented by the certificate credentials. The signature and PASSporT object are created at the application's choice of authoritative point(s) in the network.

For example, the PASSporT object could be created on a device to which a user has authenticated, or at a network entity with an authenticated trust relationship with that device and its user.  Destination identities represent the intended destination of the personal communications, i.e. the identities being called by the caller.  The destination point(s) determined by the application need to have the capability to verify the PASSporT token and the digital signature.  The PASSporT associated certificate is used to validate the authority of the originating signer, generally via a certificate chain to the trust anchor for that application.

= Section 5.2.1 =

s/The "dest" is a JSON object/The "dest" claim is a JSON object/

= Section 5.2.2 =

OLD
The "mky" claim value JSON array MUST
   contain JSON objects with exactly one of both corresponding "alg" and
   "dig" claim objects.  The order of the JSON array should be in
   lexicographic order of the "alg" claims first followed by the
   corresponding lexicographic order of the "dig" claim values when
   there is repeated "alg" claims.

NEW
The "mky" claim value JSON array MUST
   contain JSON objects with exactly one of both corresponding "alg" and
   "dig" claim objects.  The order of the JSON array should be in
   lexicographic order of the "alg" claims. If the array contains multiple identical "alg" claims, those should be ordered in the lexicographic order of their associated "dig" claims.
   
= Section 7 =
   
s/the Compact form/the compact form/

s/In order to construct the Compact form of the PASSporT string, the/In order to construct the Compact form of the PASSporT string, follow the/