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

Chris Wendt <> Fri, 22 April 2016 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93A0712E4C3 for <>; Thu, 21 Apr 2016 17:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c6iqrveZOgqN for <>; Thu, 21 Apr 2016 17:56:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64B9512E33F for <>; Thu, 21 Apr 2016 17:56:52 -0700 (PDT)
Received: by with SMTP id r184so33106450qkc.1 for <>; Thu, 21 Apr 2016 17:56:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=TLUifLiS7jMggNZMbXc7DBodHzyKQnJeGiZgsYn+Xnk=; b=kncArM1Y9nqpydtdrpJdB5O2RAxKT4L//Uh7Dp5EtVffdclO0iaOqttCfdCGoyt0WE 70814d2RTklrDIf2KW3mNdJj83yzJ7eyLlIi70V6LTu0uT0WYjdDRPZ2Si4lFuBlVUDN G5n12EUFglJSX/a7JKNtPOzMXcuyf56KGSbFxdusihyB5GH0IUK8mmryOnic+Um7Oi3f KFob5Q48GhLBy0wkV6ZC7bDz7sGigZT94dQgfL/1Ru6493oYyFRVnw3CoUsTXWyxBQ6F aWcZs0wpgdxFD4lN7DI2kiTjQvJdSucoLXpCLlV7/ujGilDY5Axiyht04IVz3LEM/FP1 wJjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TLUifLiS7jMggNZMbXc7DBodHzyKQnJeGiZgsYn+Xnk=; b=ONPmSo49xGo8WHKGPFqtYZyBBmPTe25EKvEpj8RuzCjF0BrTNPBHLJdF8p3hGPr0TW f52qm7K1NbC5hqK4ZgW1bG1a/sCF0LChipymqv0JdhsMgVXkg056m2XRow1ixU/2AYJR 17vWuaUCkIXfGQlyDs+zWmJlMhouIt4j2hkfQajZY+NBBx9YQWT58qaHZovaF3ECpoat p+uDD7y+3+edGapt5kL11H5/Qn3K55ONygXp/mvBp0Fhz6FYOLePKRxgd+xb4pkdU2cj as3ljVzalnbvzY57cnBTXKO2bUwjyImWsR6sjgu6+y6b597/6+kcvqB/caDlefg4mGgT mrBA==
X-Gm-Message-State: AOPr4FXuHgAxRPKUCyYrwhsJFPwPEEyQQEo1MoAq4cMmLJJYKeE57ywFQPa4xTMSrEXl9A==
X-Received: by with SMTP id h18mr23129090qke.58.1461286611449; Thu, 21 Apr 2016 17:56:51 -0700 (PDT)
Received: from ?IPv6:2601:41:c101:9364:1cce:a470:49b7:fba7? ([2601:41:c101:9364:1cce:a470:49b7:fba7]) by with ESMTPSA id e127sm1414194qkb.34.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Apr 2016 17:56:51 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1B7E25E7-E2FE-4E5C-837F-F0A170D56439"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Chris Wendt <>
In-Reply-To: <>
Date: Thu, 21 Apr 2016 20:56:48 -0400
Message-Id: <>
References: <> <> <>
To: Russ Housley <>
X-Mailer: Apple Mail (2.3124)
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 00:56:54 -0000

> On Apr 21, 2016, at 4:26 PM, Russ Housley <> wrote:
> Jon:
>> 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.
> Thanks.


>>> (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 <>