Re: [stir] A few comments on the PASSporT Document

Richard Shockey <> Fri, 22 April 2016 01:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 475DD12EB08 for <>; Thu, 21 Apr 2016 18:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (768-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qbXLAzSjqB7g for <>; Thu, 21 Apr 2016 18:21:48 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id D802C12E916 for <>; Thu, 21 Apr 2016 18:21:47 -0700 (PDT)
Received: (qmail 28891 invoked by uid 0); 22 Apr 2016 01:21:47 -0000
Received: from unknown (HELO cmgw2) ( by with SMTP; 22 Apr 2016 01:21:47 -0000
Received: from ([]) by cmgw2 with id lDMe1s00Q1MNPNq01DMhSY; Thu, 21 Apr 2016 19:21:45 -0600
X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=8WrITzYgnNwA:10 a=p-_XEfp0GhYA:10 a=kziv93cY1bsA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=w1VtefKfAAAA:8 a=tGX7uwomAAAA:8 a=hGBaWAWWAAAA:8 a=wqCdSphEAAAA:8 a=QSof3KEQRY8zfnz_rc0A:9 a=NRCzwpkS4axj99lh:21 a=RhqpYOTD1HniYxwe:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=aY2WEzcl6vMYlDi6DLoA:9 a=_pogsq4XmJkgCYMF:21 a=QJkJdB0RUcPyXaMe:21 a=JIiHooqc4NY2MAIk:21 a=_W_S_7VecoQA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:CC: To:From:Subject:Date; bh=7eJdAih/YnBpQG5GmCCIFA3cuVlx4RPqMtiN5p9iqQ4=; b=feU6 +WVeN5X87u0ccfne3UB3JJVSlNnIrETF7KFLcxPOlxM0kzmrTVZiRBvFqNuoRJSkhLrn2vuzrk58h m2bmSz/ybU21rFx0Y3C4mGhwxgRpuucH9/2SZuTnAnCwGzv;
Received: from [] (port=49958 helo=[]) by with esmtpa (Exim 4.86_2) (envelope-from <>) id 1atPmu-0001Fv-6B; Thu, 21 Apr 2016 19:21:40 -0600
User-Agent: Microsoft-MacOutlook/f.15.1.160411
Date: Thu, 21 Apr 2016 21:21:32 -0400
From: Richard Shockey <>
To: Chris Wendt <>, Russ Housley <>
Message-ID: <>
Thread-Topic: [stir] A few comments on the PASSporT Document
References: <> <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3544118500_632296364"
X-Identified-User: {} {sentby:smtp auth authed with}
Archived-At: <>
Cc: IETF STIR Mail List <>, Jon Peterson <>
Subject: Re: [stir] A few comments on the PASSporT Document
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Apr 2016 01:21:51 -0000

And please more examples.  The vendor community is begining  to ask serious questions about time tables and roadmaps.  The commitment to deploy is very real. 

Where does this actually show up in the headers. What does or should it look like? 

How this might show up on UA’s is another issue but totally out of scope for this WG now and in the future. 

Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

From:  stir <> on behalf of Chris Wendt <>
Date:  Thursday, April 21, 2016 at 8:56 PM
To:  Russ Housley <>
Cc:  IETF STIR Mail List <>, Jon Peterson <>
Subject:  Re: [stir] A few comments on the PASSporT Document

On Apr 21, 2016, at 4:26 PM, Russ Housley <> wrote:


Thanks for these notes Russ.

I needed to chase a bunch of references to figure out what really goes in
the iat claim.  This leads me to two comments.

(1)  Let¹s help the reader and tell them that the iat claim contains a
JSON numeric value representing the number of seconds from 1970-01-01
00:00:00 UTC.

Sounds good to me. That claim is defined in baseline JWS/JWT, but agreed
it would be helpful to informationally reiterate its syntax in the
PASSporT spec.



(2) The iat claim carries the time that the token was issued.  Section 7
tells that the token should be handled in a "reasonable for clock drift
and transmission time.²  This makes sense, but neither Section
nor Section 7 tells what ought to happen if it is determined to be stale.

This is where the hand-off between RFC4474bis and PASSporT can be murky.
The behavior for SIP as a using protocol of PASSporT with regards to the
freshness of Date/iat is given in RFC4474bis. Other using protocols might
want to use other means to ascertain freshness; SIP behavior really comes
down to comparing iat with the Date header, and we don't want that
using-protocol-specific language to be in PASSporT.

I can also imagine PASSporT tokens being evaluated historically, rather
than in real time, and the determination of "freshness" for those purposes
might be different, or even just irrelevant.

What we can say about iat in PASSporT though is that using protocols are
required to specify how they determine freshness (like, what they compare
it to). Would that make sense as a way to approach this?

Yes, that makes sense to me.


The syntax of the mky claim seems to go against a JOSE design principle.
JOSE used very compact representations for everything.  However, the mky
claim uses a whole lot of colons.  This leads to a third comment.

(3) To align with the JOSE principle, should the mky claim syntax use a
hex string or a base64 string to carry the hash values.

Jonathan Lennox provided some compelling reasons for us to move mky to a
JSON array format, similar to what WebRTC has done (so it's clear which
keys can match to which m= lines in SDP, say). That at least was my
take-away from the discussions around this in Buenos Aires. Would that be
satisfactory for you?

I think so.

So, Jon, the idea is to use this format?

       "fingerprint": [ {
         "algorithm": "sha-256",
         "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB"
       }, {
         "algorithm": "sha-1",
         "digest": "74:E9:76:C8:19:...:F4:45:6B"
       } ]

(from 5.6.4) in draft-ietf-rtcweb-security-arch-11

I’m not sure that addresses the size part, do we need the colon’s as Russ suggests?
Maybe use smaller key’s?

       "fp": [ {
         "alg": "sha-256",
         "dgst": "4AADB9B13F...E57CAB"
       }, {
         "alg": "sha-1",
         "dgst": "74E976C819...F4456B"
       } ]

Could do even further encoding of fingerprint to reduce size as suggested in


_______________________________________________ stir mailing list