Re: [stir] OCSP and short-lived certs

Roman Shpount <roman@telurix.com> Fri, 13 January 2023 19:24 UTC

Return-Path: <roman@telurix.com>
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 DE597C15C52D for <stir@ietfa.amsl.com>; Fri, 13 Jan 2023 11:24:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level:
X-Spam-Status: No, score=-1.995 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=telurix.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4HR-rHqXVLE for <stir@ietfa.amsl.com>; Fri, 13 Jan 2023 11:24:39 -0800 (PST)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B266C1526FF for <stir@ietf.org>; Fri, 13 Jan 2023 11:24:39 -0800 (PST)
Received: by mail-oi1-x232.google.com with SMTP id d127so18428653oif.12 for <stir@ietf.org>; Fri, 13 Jan 2023 11:24:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=TO2KjDuKQsZWndI91eqdgcUSU9QRt7fmcgPXqnpbcDQ=; b=UQ3qYjO5wL5/v5WM5Cy5BPkdrTd0+VAzfu2hJEg+znWNKqix8xywXCGFmtkXdD7URE tm3o5I/1CN23kVDHsbUaDyhpwBxgp7DaVHAgu9oNm9tSEXgHtyC7sZdfNQdK4LuSI87h RosxPWOj/rIk448qQtGKbnJhPmdBsbThlGWZw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=TO2KjDuKQsZWndI91eqdgcUSU9QRt7fmcgPXqnpbcDQ=; b=vbIYdQb/1EX744HZx42tbRykdtLVoUGdObMRWbNW66h0VsKNX0WINsIgDIcFx9AbfO 5aYSGQEx80y8SI/yInQTNm7Qe7ASm/L+KB1F6WReWDqvrAOpStiG5ylFA9KlOq2+FbYf lOYRverng7E112tVl32i8vb0wObZOvQdOM5dav8YZ3ieWWo2u2HIk6alVEalFm0cPLCT yzs7f5WCrfEdthsL08slAmQMqattoaa4OrLizO2n7ogx/Qj9rPSfbZbqtqz2revW6AiC intJJAFy0D4B7RvbXN9BvPeJLg/0IFgnEEm7XadQRmYCPnkb/UrpyB40HEtBFwI76HLR y+1Q==
X-Gm-Message-State: AFqh2krFAlwOH8jmJm5s6PUKCh/Gl3ypoee9cYW7GiAgIwXiXnSVTiau H6UeezIaMvlyuGb6CTVqwTjtH+1jZTeQgYv/
X-Google-Smtp-Source: AMrXdXuRMTNxjERI815iuNoaK7AQ854tsAvr68MgfG2V893DVEpbJJkujIzGQk/oGsZouR/NnFkcSg==
X-Received: by 2002:aca:ea41:0:b0:363:ad33:9065 with SMTP id i62-20020acaea41000000b00363ad339065mr19198553oih.53.1673637876529; Fri, 13 Jan 2023 11:24:36 -0800 (PST)
Received: from mail-oa1-f44.google.com (mail-oa1-f44.google.com. [209.85.160.44]) by smtp.gmail.com with ESMTPSA id p3-20020aca5b03000000b0035c073aa0d8sm9476057oib.18.2023.01.13.11.24.35 for <stir@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Jan 2023 11:24:36 -0800 (PST)
Received: by mail-oa1-f44.google.com with SMTP id 586e51a60fabf-15eeec85280so2200404fac.11 for <stir@ietf.org>; Fri, 13 Jan 2023 11:24:35 -0800 (PST)
X-Received: by 2002:a05:6871:828:b0:142:6396:5ca with SMTP id q40-20020a056871082800b00142639605camr4372587oap.241.1673637875485; Fri, 13 Jan 2023 11:24:35 -0800 (PST)
MIME-Version: 1.0
References: <DM5PR00MB03929E33135A1AAE6CD5E4D888F59@DM5PR00MB0392.namprd00.prod.outlook.com> <AF560837-44FD-402A-AD16-2DF5788ECFC0@team.neustar> <DM8PR11MB56693FB4DB84652EF2D3EAF299FB9@DM8PR11MB5669.namprd11.prod.outlook.com> <SN6PR00MB040000EA62E82D8C9DC9C90988FF9@SN6PR00MB0400.namprd00.prod.outlook.com> <DM8PR11MB5669A839A34F3F54B788301A99FF9@DM8PR11MB5669.namprd11.prod.outlook.com> <SN6PR00MB040014E6E373654C77C7863888FF9@SN6PR00MB0400.namprd00.prod.outlook.com> <DM8PR11MB566980BAA7CD82E45FC4CDA899FF9@DM8PR11MB5669.namprd11.prod.outlook.com> <DM5PR00MB0390CA25B85579BAB4A7AC7A88C29@DM5PR00MB0390.namprd00.prod.outlook.com> <DM8PR11MB5669F6C0B3441A376A7B608599C29@DM8PR11MB5669.namprd11.prod.outlook.com>
In-Reply-To: <DM8PR11MB5669F6C0B3441A376A7B608599C29@DM8PR11MB5669.namprd11.prod.outlook.com>
From: Roman Shpount <roman@telurix.com>
Date: Fri, 13 Jan 2023 14:24:23 -0500
X-Gmail-Original-Message-ID: <CAD5OKxscns+9KHuhfkHL_kSFs0PMAs9kSfech6fAiQAZyRvn1Q@mail.gmail.com>
Message-ID: <CAD5OKxscns+9KHuhfkHL_kSFs0PMAs9kSfech6fAiQAZyRvn1Q@mail.gmail.com>
To: Alec Fenichel <alec.fenichel=40transnexus.com@dmarc.ietf.org>
Cc: Jack Rickard <jack.rickard@microsoft.com>, "Peterson, Jon" <jon.peterson=40team.neustar@dmarc.ietf.org>, IETF STIR Mail List <stir@ietf.org>, Simon Castle <simoncastle@microsoft.com>
Content-Type: multipart/alternative; boundary="0000000000000d318705f22a2fea"
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/EE2PbAdsMJHraoDo5GEalzS95JQ>
Subject: Re: [stir] OCSP and short-lived certs
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 13 Jan 2023 19:24:44 -0000

Hi Alec,

There are two size limits we should be concerned about.

The first limit is 1500 bytes, which is now largely irrelevant for anything
sending Identity. INVITE messages with Identity are larger than 1500 bytes.

The second limit is around 9200 bytes. Once you go past that limit, you are
no longer able to use UDP and must use TCP or TLS for INVITE messages. If
adding the whole chain causes INVITE to go beyond this size, SIP networks
are going to have major problems.

Best Regards,
_____________
Roman Shpount


On Fri, Jan 13, 2023 at 1:55 PM Alec Fenichel <alec.fenichel=
40transnexus.com@dmarc.ietf.org> wrote:

> Hey Jack,
>
>
>
> In my experience, the size of SIP INVITEs has not been a significant
> problem.
>
>
>
> I also worry about cache poisoning with this cache method.
>
>
>
> I think the advantages (simplicity and compatibility with existing
> libraries) of using the full chain (without the root) out way the
> disadvantages (larger PASSporT size).
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Chief Technology Officer
>
> TransNexus <https://transnexus.com/>
>
> alec.fenichel@transnexus.com
>
> +1 (404) 369-2407 <+14043692407>
>
>
>
> *From: *Jack Rickard <jack.rickard@microsoft.com>
> *Date: *Friday, January 13, 2023 at 10:21
> *To: *Alec Fenichel <alec.fenichel@transnexus.com>, Peterson, Jon
> <jon.peterson=40team.neustar@dmarc.ietf.org>, IETF STIR Mail List <
> stir@ietf.org>
> *Cc: *Simon Castle <simoncastle@microsoft.com>
> *Subject: *RE: OCSP and short-lived certs
>
> I don’t think Example 1 is a problem as you cache by Subject and Key ID
> not Issuer and Key ID, and those certs have different subjects.
>
> Example 2 is a pain, I think the answer is that you need to cache multiple
> certs per key and then just try all of them, this theoretically could get
> very complex (although in practice is likely to remain simple) as you
> essentially end up needing to do a graph search. TnAuthList hierarchy could
> make it even more of a pain.
>
>
>
> This does all feel nasty, and after an internal discussion I might be
> worrying too much about the size of the invite, but I don’t know for sure.
> I would be happy to just use x5c as it currently exists, if someone can
> confidently say this 2-3x increase in the size of an identity isn’t going
> to be a problem.
>
>
>
> Jack
>
>
>
> *From:* Alec Fenichel <alec.fenichel@transnexus.com>
> *Sent:* Tuesday, January 10, 2023 7:11 PM
> *To:* Jack Rickard <jack.rickard@microsoft.com>; Peterson, Jon
> <jon.peterson=40team.neustar@dmarc.ietf.org>; IETF STIR Mail List <
> stir@ietf.org>
> *Cc:* Simon Castle <simoncastle@microsoft.com>
> *Subject:* [EXTERNAL] Re: OCSP and short-lived certs
>
>
>
> I think there are some issues with that cache key logic.
>
>
>
>
>
> *Example 1:*
>
>
>
> Let’s say there is a root certificate, R1:
>
>                 Subject: Root 1
>
>                 Issuer: Root 1
>
>                 Subject Key ID: root1
>
>                 Authority Key ID: root1
>
>
>
> Let’s say there are two 2 intermediate certificates, I1 and I2, that use
> the same key pair but different Subject DNs:
>
>                 I1:
>
>                                 Subject: Intermediate 1
>
>                                 Issuer: Root 1
>
>                                 Subject Key ID: intermediate1
>
>                                 Authority Key ID: root1
>
>                 I2:
>
>                                 Subject: Intermediate 2
>
>                                 Issuer: Root 1
>
>                                 Subject Key ID: intermediate1
>
>                                 Authority Key ID: root1
>
>
>
> Let’s say there are two 2 end-entity certificates, E1 and E2:
>
>                 E1:
>
>                                 Subject: End-entity 1
>
>                                 Issuer: Intermediate 1
>
>                                 Subject Key ID: end1
>
>                                 Authority Key ID: intermediate1
>
>
>
>                 E2:
>
>                                 Subject: End-entity 2
>
>                                 Issuer: Intermediate 2
>
>                                 Subject Key ID: end2
>
>                                 Authority Key ID: intermediate1
>
>
>
> When you receive E1 for the first time, how would you I1 in such a way
> that it does not conflict with I2 when you receive E2? I1 and I2 have the
> same Issuer and Subject Key ID.
>
>
>
>
>
>
>
>
>
> *Example 2:*
>
>
>
> Let’s say there is a root certificate, R1:
>
>                 Subject: Root 1
>
>                 Issuer: Root 1
>
>                 Subject Key ID: root1
>
>                 Authority Key ID: root1
>
>
>
> Let’s say there are two 2 intermediate certificates, I1 and I2, that use
> the same key pair, the same Subject DN, but have different CP versions:
>
>                 I1:
>
>                                 Subject: Intermediate 1
>
>                                 Issuer: Root 1
>
>                                 Subject Key ID: intermediate1
>
>                                 Authority Key ID: root1
>
>                                 CP: 1
>
>                 I2:
>
>                                 Subject: Intermediate 1
>
>                                 Issuer: Root 1
>
>                                 Subject Key ID: intermediate1
>
>                                 Authority Key ID: root1
>
>                                 CP: 2
>
>
>
> Let’s say there are two 2 end-entity certificates, E1 and E2:
>
>                 E1:
>
>                                 Subject: End-entity 1
>
>                                 Issuer: Intermediate 1
>
>                                 Subject Key ID: end1
>
>                                 Authority Key ID: intermediate1
>
>                                 CP: 1
>
>
>
>                 E2:
>
>                                 Subject: End-entity 2
>
>                                 Issuer: Intermediate 1
>
>                                 Subject Key ID: end2
>
>                                 Authority Key ID: intermediate1
>
>                                 CP: 2
>
>
>
> I1 does not form a valid chain for E2 because the CPs are different. How
> would you cache I1 and I2 in such a way that they don’t conflict, but you
> are also able to determine the cache key with just E1 or E2?
>
>
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Chief Technology Officer
>
> TransNexus
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexus.com%2F&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200995996259%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MhSI%2FZ8Qjm%2F3UboVKCUAnVaGoi%2BbQI6C1HAi3Lob7I8%3D&reserved=0>
>
> alec.fenichel@transnexus.com
>
> +1 (404) 369-2407 <+14043692407>
>
>
>
> *From: *Jack Rickard <jack.rickard@microsoft.com>
> *Date: *Tuesday, January 10, 2023 at 13:35
> *To: *Alec Fenichel <alec.fenichel@transnexus.com>, Peterson, Jon <
> jon.peterson=40team.neustar@dmarc.ietf.org>, IETF STIR Mail List <
> stir@ietf.org>
> *Cc: *Simon Castle <simoncastle@microsoft.com>
> *Subject: *RE: OCSP and short-lived certs
>
> I agree it makes things more complicated, and you need and
> application-level (or plausibly domain-level) cache. However, OpenSSL can
> already do this (see /docs/man3.1/man3/X509_STORE_CTX_set0_untrusted.html
> (openssl.org)
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.openssl.org%2Fdocs%2Fman3.1%2Fman3%2FX509_STORE_CTX_set0_untrusted.html&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ck8CSNcLUgwMmgXHowCdmD0ute3940CottS5KDcai4Q%3D&reserved=0>),
> you cache based on the issuer name and subject key identifier, as you can’t
> change either of those without having to re-issue the child cert.
>
>
>
> I agree this is not ideal. It’s possible that including the entire chain
> is fine, but my gut reaction is that it will be unacceptably large.
>
>
>
> Jack
>
>
>
> *From:* Alec Fenichel <alec.fenichel@transnexus.com>
> *Sent:* Tuesday, January 10, 2023 5:43 PM
> *To:* Jack Rickard <jack.rickard@microsoft.com>; Peterson, Jon <
> jon.peterson=40team.neustar@dmarc.ietf.org>; IETF STIR Mail List <
> stir@ietf.org>
> *Cc:* Simon Castle <simoncastle@microsoft.com>
> *Subject:* [EXTERNAL] Re: OCSP and short-lived certs
>
>
>
> Jack,
>
>
>
> My concern with partial chains is that it dramatically increases the
> complexity.
>
>
>
> How do you cache (it is no longer an HTTP cache but an application-level
> cache)? Specifically, what is the cache key and value? You need to be able
> to deterministically construct the cache key for both the end-entity and
> intermediate certificate. Certificates can be re-issued with the same or
> different CN as well as the same or different key pair.
>
>
>
> This likely would prevent the use of existing libraries for JWT validation
> and caching.
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Chief Technology Officer
>
> TransNexus
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexus.com%2F&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CGpDSuxX%2FwJM7Q%2BaM606SqIlzkBoedJnP2DxPfZVCd0%3D&reserved=0>
>
> alec.fenichel@transnexus.com
>
> +1 (404) 369-2407 <+14043692407>
>
>
>
> *From: *Jack Rickard <jack.rickard@microsoft.com>
> *Date: *Tuesday, January 10, 2023 at 12:09
> *To: *Alec Fenichel <alec.fenichel@transnexus.com>, Peterson, Jon <
> jon.peterson=40team.neustar@dmarc.ietf.org>, IETF STIR Mail List <
> stir@ietf.org>
> *Cc: *Simon Castle <simoncastle@microsoft.com>
> *Subject: *RE: OCSP and short-lived certs
>
> This is roughly what I was picturing, although I do suspect including the
> whole chain would be too big, and we’d need the “x5u” and “x5c” option
> (where x5c contains a partial chain).
>
>
>
> *From:* Alec Fenichel <alec.fenichel@transnexus.com>
> *Sent:* Friday, January 6, 2023 4:26 PM
> *To:* Peterson, Jon <jon.peterson=40team.neustar@dmarc.ietf.org>; Jack
> Rickard <jack.rickard@microsoft.com>; IETF STIR Mail List <stir@ietf.org>
> *Cc:* Simon Castle <simoncastle@microsoft.com>
> *Subject:* [EXTERNAL] Re: OCSP and short-lived certs
>
>
>
> I think “Short-lived certs with stapling” is extremely easy to add support
> for and we should allow it. Either in addition to or instead of the “x5u”
> claim with the URL of the certificate chain, we should allow the “x5c”
> claim with the chain of certificates. In order to keep in compliance with
> existing JWS behavior, I think we should just include the full chain
> (excluding the root just like we do for “x5u”). If we want to only include
> the leaf, then we would need to require the “x5u” to have the full chain
> and the “x5c” to have just the leaf.
>
>
>
>
>
>
>
> *Example with “x5u”:*
>
>
>
> {
>
>   "alg": "ES256",
>
>   "ppt": "shaken",
>
>   "typ": "passport",
>
>   "x5u": "
> https://certificates.clearip.com/908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01/cc54a11039de67bacd9b6019443cecdb.pem
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcertificates.clearip.com%2F908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01%2Fcc54a11039de67bacd9b6019443cecdb.pem&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TozVFinmQBo7y54qDpLCDAWgglmmvdEvMr7YRlFju4Q%3D&reserved=0>
> "
>
> }
>
> {
>
>   "attest": "C",
>
>   "dest": {
>
>     "tn": [
>
>       "18609653208"
>
>     ]
>
>   },
>
>   "iat": 1668548175,
>
>   "orig": {
>
>     "tn": "14077600036"
>
>   },
>
>   "origid": "2de926c8-2be8-44c6-8e9c-0258a407b018"
>
> }
>
>
>
>
>
>
>
> *Example with “x5c”:*
>
>
>
> {
>
>   "alg": "ES256",
>
>   "ppt": "shaken",
>
>   "typ": "passport",
>
>   "x5c": [
>
>
> "MIIC+DCCAp6gAwIBAgIQejOopoqGo5lSxqy0y95LDDAKBggqhkjOPQQDAjBnMQswCQYDVQQGEwJVUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSwwKgYDVQQDEyNUcmFuc05leHVzLCBJbmMuIFNIQUtFTiBJc3N1aW5nIENBMzAeFw0yMjExMTMyMDMxMjlaFw0yMjExMjAyMDMxMjhaMFUxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZUcmFuc05leHVzIERldmVsb3BtZW50MQ8wDQYDVQQLEwZTSEFLRU4xFDASBgNVBAMTC1NIQUtFTiA1MThKMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEax9FyDGmdfjAES9quPIDg5nPordCq3QiAj1MkWX3ptRQSxD8U3AziaUeqJC/vuFv47JVsO0rxHvwzza/zqkx16OCATwwggE4MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBQIqucXuD9WMdR1sUEPu7rLsFw1+DAfBgNVHSMEGDAWgBS7lt4xEs3TlpmEpDYwYDzXUoF9JzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwSBnjCBmzCBmKA6oDiGNmh0dHBzOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25sb2FkL3YxL2NybKJapFgwVjEUMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQYDVQQDDApTVEktUEEgQ1JMMQswCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMBYGCCsGAQUFBwEaBAowCKAGFgQ1MThKMAoGCCqGSM49BAMCA0gAMEUCIQDszGSsxrW+dDq5SwuZe/xoW8yO6gMVW503owuYuchH5wIgV2+59q2m9mV51t8hIxidKLMgnlLqJ5rre/KLSegGVOI=",
>
>
> "MIIC8TCCApigAwIBAgIQaeMkSbXPfDSfEkC20T6VZTAKBggqhkjOPQQDAjBkMQswCQYDVQQGEwJVUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSkwJwYDVQQDEyBUcmFuc05leHVzLCBJbmMuIFNIQUtFTiBSb290IENBMTAeFw0yMTA4MjAwMDAwMDBaFw0zMTA4MTkyMzU5NTlaMGcxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBUcmFuc05leHVzLCBJbmMuMQ8wDQYDVQQLEwZTSEFLRU4xLDAqBgNVBAMTI1RyYW5zTmV4dXMsIEluYy4gU0hBS0VOIElzc3VpbmcgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEedxAVLKoKQD8g8QPsb9EqRyITRIDArijIRVn1QSXV3Oh7H5HsWihLlTqgbnVM7zF/nXicWvV/kkgvIKOfmCpW6OCAScwggEjMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBS7lt4xEs3TlpmEpDYwYDzXUoF9JzAfBgNVHSMEGDAWgBSajEoZn2TEXjO2KYwWyqe4EEsuWzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwSBnjCBmzCBmKA6oDiGNmh0dHBzOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25sb2FkL3YxL2NybKJapFgwVjEUMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQYDVQQDDApTVEktUEEgQ1JMMQswCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMAoGCCqGSM49BAMCA0cAMEQCIGgZROhV4BF/KGMwnKGbSUJ0VMdMavpq1jSifXhtc7B3AiA6ODY5dkKtrUbywLLH+ZJX1UnDad6FZwwQVQpUD0oZHA=="
>
>   ]
>
> }
>
> {
>
>   "attest": "C",
>
>   "dest": {
>
>     "tn": [
>
>       "18609653208"
>
>     ]
>
>   },
>
>   "iat": 1668548175,
>
>   "orig": {
>
>     "tn": "14077600036"
>
>   },
>
>   "origid": "2de926c8-2be8-44c6-8e9c-0258a407b018"
>
> }
>
>
>
>
>
>
>
> *Example with both “x5u” and “x5c” (for backwards compatibility with VSs
> that don’t support “x5c”):*
>
>
>
> {
>
>   "alg": "ES256",
>
>   "ppt": "shaken",
>
>   "typ": "passport",
>
>   "x5u": "
> https://certificates.clearip.com/908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01/cc54a11039de67bacd9b6019443cecdb.pem
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcertificates.clearip.com%2F908bf82d-0ce7-4c00-a9e8-84a0c1b5cd01%2Fcc54a11039de67bacd9b6019443cecdb.pem&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=TozVFinmQBo7y54qDpLCDAWgglmmvdEvMr7YRlFju4Q%3D&reserved=0>
> "
>
>   "x5c": [
>
>
> "MIIC+DCCAp6gAwIBAgIQejOopoqGo5lSxqy0y95LDDAKBggqhkjOPQQDAjBnMQswCQYDVQQGEwJVUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSwwKgYDVQQDEyNUcmFuc05leHVzLCBJbmMuIFNIQUtFTiBJc3N1aW5nIENBMzAeFw0yMjExMTMyMDMxMjlaFw0yMjExMjAyMDMxMjhaMFUxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZUcmFuc05leHVzIERldmVsb3BtZW50MQ8wDQYDVQQLEwZTSEFLRU4xFDASBgNVBAMTC1NIQUtFTiA1MThKMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEax9FyDGmdfjAES9quPIDg5nPordCq3QiAj1MkWX3ptRQSxD8U3AziaUeqJC/vuFv47JVsO0rxHvwzza/zqkx16OCATwwggE4MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMB0GA1UdDgQWBBQIqucXuD9WMdR1sUEPu7rLsFw1+DAfBgNVHSMEGDAWgBS7lt4xEs3TlpmEpDYwYDzXUoF9JzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwSBnjCBmzCBmKA6oDiGNmh0dHBzOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25sb2FkL3YxL2NybKJapFgwVjEUMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQYDVQQDDApTVEktUEEgQ1JMMQswCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMBYGCCsGAQUFBwEaBAowCKAGFgQ1MThKMAoGCCqGSM49BAMCA0gAMEUCIQDszGSsxrW+dDq5SwuZe/xoW8yO6gMVW503owuYuchH5wIgV2+59q2m9mV51t8hIxidKLMgnlLqJ5rre/KLSegGVOI=",
>
>
> "MIIC8TCCApigAwIBAgIQaeMkSbXPfDSfEkC20T6VZTAKBggqhkjOPQQDAjBkMQswCQYDVQQGEwJVUzEZMBcGA1UEChMQVHJhbnNOZXh1cywgSW5jLjEPMA0GA1UECxMGU0hBS0VOMSkwJwYDVQQDEyBUcmFuc05leHVzLCBJbmMuIFNIQUtFTiBSb290IENBMTAeFw0yMTA4MjAwMDAwMDBaFw0zMTA4MTkyMzU5NTlaMGcxCzAJBgNVBAYTAlVTMRkwFwYDVQQKExBUcmFuc05leHVzLCBJbmMuMQ8wDQYDVQQLEwZTSEFLRU4xLDAqBgNVBAMTI1RyYW5zTmV4dXMsIEluYy4gU0hBS0VOIElzc3VpbmcgQ0EzMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEedxAVLKoKQD8g8QPsb9EqRyITRIDArijIRVn1QSXV3Oh7H5HsWihLlTqgbnVM7zF/nXicWvV/kkgvIKOfmCpW6OCAScwggEjMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgAGMB0GA1UdDgQWBBS7lt4xEs3TlpmEpDYwYDzXUoF9JzAfBgNVHSMEGDAWgBSajEoZn2TEXjO2KYwWyqe4EEsuWzAXBgNVHSAEEDAOMAwGCmCGSAGG/wkBAQMwgaYGA1UdHwSBnjCBmzCBmKA6oDiGNmh0dHBzOi8vYXV0aGVudGljYXRlLWFwaS5pY29uZWN0aXYuY29tL2Rvd25sb2FkL3YxL2NybKJapFgwVjEUMBIGA1UEBwwLQnJpZGdld2F0ZXIxCzAJBgNVBAgMAk5KMRMwEQYDVQQDDApTVEktUEEgQ1JMMQswCQYDVQQGEwJVUzEPMA0GA1UECgwGU1RJLVBBMAoGCCqGSM49BAMCA0cAMEQCIGgZROhV4BF/KGMwnKGbSUJ0VMdMavpq1jSifXhtc7B3AiA6ODY5dkKtrUbywLLH+ZJX1UnDad6FZwwQVQpUD0oZHA=="
>
>   ]
>
>
>
> }
>
> {
>
>   "attest": "C",
>
>   "dest": {
>
>     "tn": [
>
>       "18609653208"
>
>     ]
>
>   },
>
>   "iat": 1668548175,
>
>   "orig": {
>
>     "tn": "14077600036"
>
>   },
>
>   "origid": "2de926c8-2be8-44c6-8e9c-0258a407b018"
>
> }
>
>
>
>
>
>
>
> Sincerely,
>
>
>
> Alec Fenichel
>
> Chief Technology Officer
>
> TransNexus
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransnexus.com%2F&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CGpDSuxX%2FwJM7Q%2BaM606SqIlzkBoedJnP2DxPfZVCd0%3D&reserved=0>
>
> alec.fenichel@transnexus.com
>
> +1 (404) 369-2407 <+14043692407>
>
>
>
> *From: *stir <stir-bounces@ietf.org> on behalf of Peterson, Jon <
> jon.peterson=40team.neustar@dmarc.ietf.org>
> *Date: *Friday, January 6, 2023 at 09:25
> *To: *Jack Rickard <jack.rickard@microsoft.com>, IETF STIR Mail List <
> stir@ietf.org>
> *Cc: *Simon Castle <simoncastle@microsoft.com>
> *Subject: *Re: [stir] OCSP and short-lived certs
>
>
>
> A good analysis. Of things that are new here, I recall I’ve seen
> short-lived with stapling proposed before, which is potentially an
> interesting spin on things.
>
>
>
> A couple points I’d add:
>
>
>
> In terms of the problem statement, I’d hesitate to call the risk of
> revealing a list of TNs a “privacy” issue – it’s not that the privacy of
> some person is compromised by it. It’s more a corporate security and
> competition issue. Not to say that makes it an invalid concern.
>
>
>
> I’m not sure why the AIA method reveals to the CA who you are calling,
> even partially? I mean, it reveals something (probably not much, just the
> VS) about who received calls, but it’s unclear how the CA could correlate
> that with callers, and likely even callees. And the revelation that does
> happen would be the same for all non-stapled approaches, wouldn’t it?
>
>
>
> Support for OCSP seems to be pretty common in the world of PKI – I think
> some SHAKEN certs in the wild have OCSP in them already – so I don’t think
> OCSP support itself such a heavy lift. The lift is doing the extension that
> we’re specifying here, which we will have to do whether we staple or no.
>
>
>
> Also you might cite the short-lived draft:
>
>
>
>
> https://datatracker.ietf.org/doc/html/draft-peterson-stir-certificates-shortlived-03
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peterson-stir-certificates-shortlived-03__%3B!!N14HnBHF!_cKSN0UiajUHBk7cfewunxC0-wBzzIM59Yp7HSMxtfFPPf55SOu_NelhKRz8qiwB0sHGgc-d8sOuXvjk7R9eEg%24&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=pS%2FrkWyy3ClNx2M%2Blc6SNe90BLBe6JXOtMTVGUXdvkI%3D&reserved=0>
>
>
>
> … though as we’ve been trying to get OCSP over the hump, it hasn’t gotten
> a ton of energy behind it recently. If you’re interested in working on
> porting the staple mechanism that I’ve been working on for OCSP into
> short-lived, I’d definitely be up for that.
>
>
>
> But to your point about getting us to a destination: at a high level, I
> think there are use cases where the RFC 8226 AIA mechanism works for just
> fine – while some enterprises have number ranges that change frequently,
> others have numbering resources that are stable for decades. I don’t think
> there’s any good reason for us to tell people not to do that, if it works
> for me. There may be very sophisticated actors that are open to dynamic
> short-lived certs, even down to the single TN level, and others who might
> find that a bit much. And OCSP can coexist with any of this, with or
> without our extension. So I guess… I’m looking at this like we’re building
> multiple mechanisms, and not really inclined to take anything off the table
> at this point. Even if we believe that short-lived at the single TN level
> with stapling would be the most technically elegant solution, getting ACME
> STAR up looks like a much heavier lift to me than getting OCSP working,
> say.
>
>
>
> Jon Peterson
>
> Neustar (a TransUnion Company)
>
>
>
> *From: *Jack Rickard <jack.rickard@microsoft.com>
> *Date: *Wednesday, January 4, 2023 at 5:43 AM
> *To: *"Peterson, Jon" <jon.peterson@team.neustar>, IETF STIR Mail List <
> stir@ietf.org>
> *Cc: *Simon Castle <simoncastle@microsoft.com>
> *Subject: *OCSP and short-lived certs
>
>
>
> Hi all,
>
>
>
> I wanted to summarize the pros and cons of the different options around
> providing dynamic TN authorization for certificates, hopefully to clarify
> exactly what the differences are and guide us towards a destination.
>
>
>
> Issues these are attempting to solve:
>
> 1.       Existing certificate infrastructure doesn’t cope well with
> rapidly changing TN assignments (such as number portability).
>
> 2.       Some users want privacy about which numbers they own, currently
> they must provide a complete list to whoever sees their certificate.
>
> 3.       The latency added by an arbitrary URI access on the call path is
> not acceptable to some use-cases.
>
>
>
> Facts about all approaches:
>
> ·         The certificate issuer has control over the TNs that the
> certificate can sign over.
>
> ·         The certificate issuer must host a server allowing someone to
> dynamically query whether an entity has permission to use a telephone
> number.
>
> ·         Someone is going to have to do a dynamic lookup at some point,
> making issue 3 mostly a question of cache-ability.
>
>
>
> *Existing by-ref using the AIA extension:*
>
> Sticking with the existing mechanism in RFC 8226 is an available option.
> This is where the Authority Information Access extension is used to host
> the TnAuthList on a remote server (controlled by the CA). In this solution
> the AS does not need to care about the TNs it owns at all, and the VS makes
> requests to the server hosted by the CA.
>
> Pros:
>
> ·         It already exists.
>
> ·         HTTP caching headers could be used to indicate to the VS how
> long it is able to cache the information for.
>
> Cons:
>
> ·         This leaks the entire list of telephone numbers that a
> certificate has authority over.
>
> ·         Any changes to TN ownership require a completely new document
> meaning cache times must be reasonably short.
>
> ·         It is not required that the HTTP request contains caching
> information, making caching the response difficult.
>
> ·         This partially reveals to the CA who you are calling.
>
>
>
> *OCSP without stapling:*
>
> draft-ietf-stir-certificates-ocsp-03 - OCSP Usage for Secure Telephone
> Identity Certificates
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-ietf-stir-certificates-ocsp*2F%26data%3D05*7C01*7Cjack.rickard*40microsoft.com*7C28f7c73e9a4a4af57d9208dadf89668c*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638068078488875792*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C%26sdata%3DA04UQdGyeXcYAb8FeoBQajcAjUeaa7twt1QknGgL5V0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!N14HnBHF!5DOVTixvCQDENQ3tRcSwwUhlGdhJTYsUWi0AV2as4VGi324vTaGm2mx0i7N1x7zR-UIOgfqh9xwwnuYiXjG-rwvGVFN1hos%24&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xxgQeM9qJyO9pSMQ8I31cPvOWBEXUBKNN63Yha7KhGA%3D&reserved=0>.
> This extends the OCSP protocol to allow a VS to query whether a certificate
> has authority over a specific originator. Note that existing
> implementations would likely treat OCSP enabled certs as invalid (due to
> not having the TNAuthList extension).
>
> Pros:
>
> ·         This can easily cope with rapidly changing numbers as each
> request only authorises one number for an arbitrarily short period of time.
>
> ·         We could require the nextUpdate field to be present (I think)
> allowing the VS to know how long it may cache the information for.
>
> Cons:
>
> ·         This doesn’t completely solve the privacy issue; an attacker
> could use the OCSP server to enumerate all TNs that a certificate owns.
>
> ·         A verifier is unlikely to be able to cache OCSP statuses, as a
> cache is only useful if it sees multiple calls from the same originator.
>
> ·         This adds complexity to the ecosystem as CA’s must host OCSP
> servers and VSs must be enhanced to understand OCSP.
>
>
>
> *OCSP with stapling:*
>
> draft-peterson-stir-ocsp-staple-00 - OCSP Stapling for Secure Telephone
> Identity (ietf.org)
> <https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fdraft-peterson-stir-ocsp-staple*2F%26data%3D05*7C01*7Cjack.rickard*40microsoft.com*7C28f7c73e9a4a4af57d9208dadf89668c*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C638068078488875792*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C%26sdata%3DGuy*2B50ZYiOpDikMB2Bo*2FYdyWvX50W1Dy3*2FWLbmozJgc*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!N14HnBHF!5DOVTixvCQDENQ3tRcSwwUhlGdhJTYsUWi0AV2as4VGi324vTaGm2mx0i7N1x7zR-UIOgfqh9xwwnuYiXjG-rwvG7lQQYtY%24&data=05%7C01%7Calec.fenichel%40transnexus.com%7Cf40e103f8aef4973853e08daf579db45%7C8e2972a2d21d49acb00518e8ceaadee3%7C0%7C0%7C638092200996152487%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nXQIB%2FZVAP6aD43RfE1AoprJNtVk8UwxxrtqebHzBQ4%3D&reserved=0>.
> This is the same as OCSP without stapling but the AS places the OCSP
> response inside the PASSporT, so the VS does not have to retrieve it. Note
> that existing implementations would likely treat OCSP enabled certs as
> invalid (due to not having the TNAuthList extension).
>
> Pros:
>
> ·         Rapidly changing numbers can be easily dealt with, as in OCSP
> without stapling.
>
> ·         The AS is in a much better position to always have all OCSP
> staples as it can be push notified of changes, and only needs to cache
> certificates for numbers for which it signs outgoing calls.
>
> ·         This could completely protect the privacy of the certificate
> owner as the OCSP server does not have to be accessible on the internet.
>
> Cons:
>
> ·         This will make PASSporTs substantially larger as they must
> contain the OCSP staple.
>
> ·         This adds complexity to the ecosystem as CAs must host OCSP
> servers and authentication & verification services must be enhanced to
> understand OCSP.
>
>
>
> *Short-lived certs without stapling:*
>
> The CA issues short-lived certs with restricted scopes, potentially only a
> few hours and a single TN. This is already supported by the existing
> standards; we may however want to specify some mechanism for obtaining
> these short-lived certs programmatically. This conceptually is very similar
> to the OCSP without stapling option above.
>
> Pros:
>
> ·         No new standards are required, and already works.
>
> ·         This allows the most flexibility around what certificates you
> want to exist and how long those permissions last.
>
> ·         If you only ever issue certificates containing a single TN then
> this allows complete privacy, assuming the certificate URLs are not
> guessable.
>
> Cons:
>
> ·         This will add a lot of latency as a verifier is unlikely to be
> able to cache these certs, as they will expire quickly and may not be
> reused to the same destination.
>
> ·         Obtaining short lived certs is difficult as the AS and CA will
> need an API, we may be able to help by specifying something here. (A
> suggestion is ACME STAR although implementations generally use custom APIs
> here currently)
>
>
>
> *Short-lived certs with stapling:*
>
> This is identical to short-lived certs without stapling but the AS puts
> part of the certificate chain into the PASSporT; only the leaf needs to be
> stapled as the rest of the chain is more easily cached. This conceptually
> is very similar to OCSP with stapling.
>
> Pros:
>
> ·         This is likely backwards compatible with existing
> implementations; they would just have to retrieve the certificate rather
> than using the stapled one.
>
> ·         This allows the most flexibility around what certificates you
> want to exist and how long those permissions last.
>
> ·         If you only ever issue certificates containing a single TN then
> this allows complete privacy, assuming the certificate URLs are not
> guessable.
>
> ·         The AS is in a much better position to always have all required
> certs as it can be push notified of changes, and only needs to cache
> certificates for numbers for which it signs outgoing calls.
>
> Cons:
>
> ·         This will make PASSporTs a lot larger (larger even than OCSP
> stapling) as they will contain at least one certificate.
>
> ·         This adds complexity to the ecosystem as authenticators & CAs
> must communicate (again possibly ACME STAR) and verification services must
> be enhanced to understand stapled certs.
>
>
>
>
>
> Thanks for reading if you got this far! I’d appreciate your opinion as
> these all look similar; I believe we need one of the stapling options, but
> there is little difference between the two options.
>
>
>
> Jack
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>