Re: [stir] Comments on draft-ietf-stir-certificates-08

"Peterson, Jon" <> Thu, 06 October 2016 23:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 50D2D1295DB for <>; Thu, 6 Oct 2016 16:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.7
X-Spam-Status: No, score=-102.7 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_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Bm3EdIZfWKx2 for <>; Thu, 6 Oct 2016 16:02:16 -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 C2295129582 for <>; Thu, 6 Oct 2016 16:02:16 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id u96MqjAx026350; Thu, 6 Oct 2016 19:02:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version;; bh=8M8nFdS9qRfXqPbsVWHNl2o4NeU27OwLddiQeciEb0w=; b=yVrt1wKiiz+0eIZLt+nRnohucIv9V5N/ebkpRgocLPPoeFWS8jq21A3yy1Ydc9VZm6Sc lxZXKJCnJiKKCaDznIlkK/3q9ScAKIUBT6/KcTTfGtSQftML/P2Gu+jhum4oiwUlOqZR TLCBP9UpEYYZnO42eRrm1N5GLD1p0al5b/j6/rOlM+fAEF7cofy1WIezDXtOGjGwh2yc zEqa9sVLfAR8Br9HXyRrHTnpI4nop5AzJeT7BGfJxqaXijHzdO5hF5qVJfdk0LlssGN/ kdBJwwJA+xpuxiobOgr4zQnEo2iFMC85R+JhDTPBdBZCJmPeg3xjTs0pSu4tP68xbe9f 3A==
Received: from ([]) by with ESMTP id 25wj314wyn-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Thu, 06 Oct 2016 19:02:15 -0400
Received: from ([]) by ([]) with mapi id 14.03.0279.002; Thu, 6 Oct 2016 19:02:14 -0400
From: "Peterson, Jon" <>
To: Anders Kristensen <>, "" <>
Thread-Topic: [stir] Comments on draft-ietf-stir-certificates-08
Thread-Index: AQHSHQRHgAUn/aJa6U+CGG4o045+qKCcEUyA
Date: Thu, 06 Oct 2016 23:02:13 +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_D41BD82F1BBDBAjonpetersonneustarbiz_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-06_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1610060400
Archived-At: <>
Subject: Re: [stir] Comments on draft-ietf-stir-certificates-08
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: Thu, 06 Oct 2016 23:02:18 -0000

Appreciate the nit fixes here; a few responses on more substantial points.

* 7: My preference would be to not list support for SIP as mandatory for info URIs. Using SUBSCRIBE/NOTIFY feels contrived and unnecessary.

The reason we included this back when was for future compatibility with potential systems that would let you subscribe to certificates and receive updates when they were changed: we imagined this might make sense for some high-volume verification services. Given how far down the OCSP path this document goes today, perhaps that isn't strictly necessary - but I can still imagine deployments where it make might sense. Supporting SIP is basically free for SIP implementations, so it doesn't seem like much of a burden to keep this option open.

* 7: OTOH using data: might make sense. Avoids cid: issue with non-multipart support.

I don't think we'd want to make that data URL yet another parameter of the Identity header, which is already getting quite long with a full form PASSporT. I don't think it's unreasonable to have a way to carry a certificate by-value in a header, though I'd look to future work for that.

* 8: So TNAuthorizationList is List<List<TNEntry>>. Why can't it just be List<TNEntry>?

The original justification for this, I think I dimly recall, was that we were going to have other categories than TNAuthorizationList under TNAuthorization - but that was many moons ago. I think at this point we can safely collapse that down into one level.

* 8: I'm not sure if ServiceProviderIdentifierList is supposed to contain SPID, Alt SPID and Last Alt SPID in that order. For example, if a cert contains a TNEntry with a spid of length 2 then those two entries would be expected to match SPID and Alt SPID of the calling number respectively?

It hadn't occurred to me that the order might be significant to relying parties. Is there any reason it would be? As far as I know, the question is whether the relying party trusts any of the SPIDs that might appear in this array; the ordering shouldn't be significant.

* 9.2: ISTM that if OCSP is always used to check freshness of TN auth lists then the actual content of the list is irrelevant. The authority check has just been delegated to the CA...

Agreed that if you use OCSP the way this section describes, then yes, the cert is basically just delivering you the tools to query OCSP, and you might as well not even bother including the TN Authorization List. I think that at best, in these cases, the TN Authorization List might be used for an initial sanity check before incurring the RTT of checking OCSP. Including the TN Authorization List by value probably more useful for single telephone numbers than for ranges, in any event.

Jon Peterson
Neustar, Inc.