Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-01

Tim Hollebeek <tim.hollebeek@digicert.com> Thu, 29 March 2018 19:04 UTC

Return-Path: <tim.hollebeek@digicert.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E2351242EA for <spasm@ietfa.amsl.com>; Thu, 29 Mar 2018 12:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com
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 EGcG_B5_K-NP for <spasm@ietfa.amsl.com>; Thu, 29 Mar 2018 12:04:51 -0700 (PDT)
Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DF8120725 for <spasm@ietf.org>; Thu, 29 Mar 2018 12:04:51 -0700 (PDT)
Received: from [216.82.241.100] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-15.bemta-8.messagelabs.com id FB/D6-22406-2D83DBA5; Thu, 29 Mar 2018 19:04:50 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WSf0yMcRzH7/v8uof1tKe76ONWfhxtFteK2Q4 zmeJsyEabpeE5Pbrj7mr3nJZhimxRhHVThxL5lcqk/EgZN4oi+XVETI5wMZEx5Oaeey4//nt9 n/fr+/l8vs8+NK7ooVQ0n2XjrRbOpKaGEo9H19dq7mqbkmMeu0Hredsp15a6VmnPOZ2E9mhzH xZH6PbltlO6i45ncl1FxXdMV9n1hVxEJJNGiz49ayVpuLVlG8o4WYGyOoo7yGyUU4B2oKE0wX 7EoKG+lRQPCtaOQfYeJyEdXiDwbG/zaUNoio0BV1MLJnIoOw9K6/f7GWdnQlnDblJkJbsEHrU XEpKTBM97dgV8PXw4csZfh2Aj4fT+236HYVPAc6RDLjU7jkP/g8/+C0N8RWs6y+UiI3Y4fGut CjQLgyevyvwMbCh0322jJB4G79xeUvJT4GC/M/BdDTXvuwJ+BNwry/e/Gdg6DG46upEUaKDPb sclXgC9zVsoSXqJoMp+gpSCKLhz2Bm4sBa+5jkC0i4E3eWX5dKhAgfXuRuBfuFgv9KCS4GTgs OeIn+gYFOhqHJwwJ8Y1JUs2Y2iHP+8z+G7g7NlCAa6vJTD/6dC4GbJK0KSosBe7QnwBDhW3ot LPB2Kf1ylJB4DRfndcomnQO/1T+gQoivReIG3ZvJWTezkaL3VmGawmTmjSRMbo40284LApfEm Ti9Er0o31yLfzm2WydAF9KQl3olG0Jh6GJPa3pisCNanp643cIJhhXWdiRecKJym1cBM9e2mI sTKp/FZq40m3+IOxkAHqUOZaDFmhAzOLBjTpKgVaeiBur0FuIKwpFt4VRiDiRIrSoZ1lj8lBt f/HopQKRkkk8kUQRm81Wy0/Z97UBiN1EomVqwSZLTY/nTy+IbAfEOEbmwUh7BxfyNVNlLC65q iSbNHjrP8asJKEryXXLrFzQ0nml1504O/514vnKM/lJLEPh0xLe4kuan9/tjEhVWsITu1BP/R 2HZ2w6LIpUeVGZnx1Ulv3HPbepbXqoJHbW3cc967t++dbef50RMnadbMeDP/obsz8dvp1QdvP 5t11rss5+tC5gB2yo1/qEy4piYEAxcbhVsF7je+Jk0X+QMAAA==
X-Env-Sender: tim.hollebeek@digicert.com
X-Msg-Ref: server-13.tower-220.messagelabs.com!1522350288!198222802!1
X-Originating-IP: [216.32.181.178]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.9.15; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4792 invoked from network); 29 Mar 2018 19:04:49 -0000
Received: from mail-by2nam01lp0178.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.178) by server-13.tower-220.messagelabs.com with AES256-GCM-SHA384 encrypted SMTP; 29 Mar 2018 19:04:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RwcreAg0RI7YOFILVqPfE/PbqRrMMMJ2Jj+r0kSbFx8=; b=e9J0IYVTkCER1i8jhXPiMuAQd78MYmxiA1zDySveOFwCEAcQM+n+7QnvYcq0byrjWTVa56XF7gK8zp9ksE/IVzGKsG+qvCY/ZwZwhwG5GAL95tSn0rK15vy4wwoXK2BHMd5KcBL9tE2ROl7DHVBulHgdnXXQFHNhHm2bOFcuSYA=
Received: from MWHPR14MB1376.namprd14.prod.outlook.com (10.173.232.139) by MWHPR14MB1711.namprd14.prod.outlook.com (10.171.147.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.631.10; Thu, 29 Mar 2018 19:04:45 +0000
Received: from MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd]) by MWHPR14MB1376.namprd14.prod.outlook.com ([fe80::ad66:bb50:b8e8:9dfd%17]) with mapi id 15.20.0609.012; Thu, 29 Mar 2018 19:04:45 +0000
From: Tim Hollebeek <tim.hollebeek@digicert.com>
To: Stefan Santesson <stefan@aaa-sec.com>, Yoav Nir <ynir.ietf@gmail.com>
CC: LAMPS <spasm@ietf.org>, Russ Housley <housley@vigilsec.com>
Thread-Topic: [lamps] Considerations and Clarifications about draft-nir-saag-star-01
Thread-Index: AQHTwRW4eNEoTpa7PEmoGQqs7AdAaKPkQq+AgAAB0ICAAEBQAIABfj2AgADK/ICAAJPQAIAAAGIAgAA8d6A=
Date: Thu, 29 Mar 2018 19:04:45 +0000
Message-ID: <MWHPR14MB1376F3F4879A97C3130D021783A20@MWHPR14MB1376.namprd14.prod.outlook.com>
References: <bec28481-d4ff-5e6f-48bc-59c55c385321@openca.org> <30637C44-5EF8-4286-A796-E5D8D91CD01A@vigilsec.com> <4843f85b-737b-5a01-bbd4-a081b55a045a@cs.tcd.ie> <C52393D3-AFA2-4AC4-AEEF-CC9F2028A4AA@aaa-sec.com> <A2366323-0AC7-481F-9348-3721C5585CA7@vigilsec.com> <DB22038E-FE18-40A2-AC84-CE4D616F53A8@aaa-sec.com> <746E17EC-9FBF-4110-8FB2-46F1D1A467D5@gmail.com> <5D8C173D-5EED-4518-927D-5B3C1D2BFE1D@aaa-sec.com>
In-Reply-To: <5D8C173D-5EED-4518-927D-5B3C1D2BFE1D@aaa-sec.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [98.111.253.132]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR14MB1711; 7:gvsZp6Pq/2dERyqKFaWfDc1ae/7ZC5IUMybNanuDDK33wHd53WqOAJSrxN3vMBFLhJV1g/YEJ4UFcU2AdfZLOnflfD90h5ndGZr/vYh1xoq5w7O6Z9/cEzqk+OBRKwi+6A/lQXyJFlWl94Ry0k7O1u5O+1ldPGdZ9jTUaUKFYhMjLTp3iH7yR5xhzkHiRv4wAkQEPxsevHx517A2gQ2FZRr9XCX0Nd07w1D+J7fixzFxutzAKhNReU3BvLqTPltM
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 3dfcb4c7-a016-4522-5f7b-08d595a7ef83
x-microsoft-antispam: UriScan:(32856632585715); BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(49563074)(7193020); SRVR:MWHPR14MB1711;
x-ms-traffictypediagnostic: MWHPR14MB1711:
x-microsoft-antispam-prvs: <MWHPR14MB171136642BA7831629968F4483A20@MWHPR14MB1711.namprd14.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(278428928389397)(209352067349851)(192374486261705)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231221)(944501327)(52105095)(93006095)(93001095)(10201501046)(3002001)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:MWHPR14MB1711; BCL:0; PCL:0; RULEID:; SRVR:MWHPR14MB1711;
x-forefront-prvs: 0626C21B10
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(39380400002)(346002)(377424004)(53754006)(13464003)(51444003)(189003)(199004)(6506007)(316002)(3660700001)(6436002)(8676002)(7736002)(106356001)(9686003)(66066001)(59450400001)(81166006)(76176011)(53546011)(25786009)(7696005)(305945005)(55016002)(11346002)(68736007)(86362001)(966005)(4326008)(6246003)(74316002)(54906003)(110136005)(53936002)(97736004)(3846002)(6306002)(81156014)(6116002)(486005)(446003)(486005)(476003)(99286004)(39060400002)(102836004)(8936002)(229853002)(2906002)(99936001)(5250100002)(5660300001)(2900100001)(93886005)(26005)(3280700002)(33656002)(186003)(105586002)(478600001)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR14MB1711; H:MWHPR14MB1376.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: yC0kYWFV5Yj4Lyd1lv1SSGhjQXu7Wlzy+QZufVUdj2u8olp3LH0BORvF9T/CG9oQqMxeqZ6XiiYvf7dwgx4YdRyHtHUaTO/Z5J7/yIxabqI1gJcx20Ggs7WP7LSsYsdmXTX8Inw1NRCiPrZYyPnhpuyT1QzopOmZpK838NZUzJvxK7cm1in+9FH37ZCKx9k+CCEd3mGqW66K3Fvwunmi5jyltqLh+Cetv6Arib3uQAZFSdivabvUb/ApZXm6EU2BRkzKoE924AkPyQjArtBR4Zq0l+fEUdE4Zwfkmv806pOl/Ub48iAnatTi8TlXV5ClKLojlRpvI0VajJK2fr6AnA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0357_01D3C76F.42D61520"
MIME-Version: 1.0
X-OriginatorOrg: digicert.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3dfcb4c7-a016-4522-5f7b-08d595a7ef83
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2018 19:04:45.1443 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR14MB1711
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/Mko_eXs2HgPvsDlzRBRNCkoFPFA>
Subject: Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-01
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2018 19:04:55 -0000

One interesting point that I noticed yesterday is that eIDAS actually requires
that certificates contain a pointer to status information.

So there may be some barriers to being able to use revocation free Qualified
Website Authentication Certificates.

-Tim

> -----Original Message-----
> From: Spasm [mailto:spasm-bounces@ietf.org] On Behalf Of Stefan Santesson
> Sent: Thursday, March 29, 2018 11:26 AM
> To: Yoav Nir <ynir.ietf@gmail.com>
> Cc: LAMPS <spasm@ietf.org>rg>; Russ Housley <housley@vigilsec.com>
> Subject: Re: [lamps] Considerations and Clarifications about draft-nir-saag-star-
> 01
> 
> Fully agree.
> I have never suggested that a CA should be required to provide a CRL.
> I'm just saying that a CA should be allowed to if it has an interest to support
> legacy clients.
> 
> /Stefan
> 
> 
> On 2018-03-29, 17:23, "Yoav Nir" <ynir.ietf@gmail.com> wrote:
> 
>     This is true, but any CA issuing such certificates will have to maintain an
> always-on server to serve those CRLs. If the CRL DP extension is not there, they
> don’t need that server.
> 
>     Yoav
> 
>     > On 29 Mar 2018, at 9:35, Stefan Santesson <stefan@aaa-sec.com> wrote:
>     >
>     > Basically yes.
>     >
>     > At least that was the discussion. I have to check what the outcome was.
>     > Also this discussion started as "Short-lived" certs, and ended up as
> "Revocation-free" certs.
>     >
>     > This way to deal with real implementations by using both noRevAvail,
> combined with a CRLDP and an empty CRL probably don't need a standard, but
> maybe a BCP or something.
>     >
>     > /Stefan
>     >
>     >
>     >
>     > On 2018-03-28, 20:29, "Russ Housley" <housley@vigilsec.com> wrote:
>     >
>     >    Stefan:
>     >
>     >    Are us saying that it allows a relying party that does not recognize the
> non-critical noRevAvail extension to use the CRLDP extension to get an empty
> CRL?  In this way, only the relying parties that do not recognize the noRevAvail
> extension will get the latency hit?
>     >
>     >    Russ
>     >
>     >
>     >> On Mar 27, 2018, at 3:40 PM, Stefan Santesson <stefan@aaa-sec.com>
> wrote:
>     >>
>     >> We had a long discussion in ETSI about this.
>     >>
>     >> One aspect is that the absence of revocation information actually breaks
> several implementations.
>     >> One idea was to publish an empty CRL + an extension with the semantics
> = "You may skip the rev checking, because the CRL is empty"
>     >>
>     >> This way you would have the cake and eat it too. Old systems would use
> the CRL and work. New systems would understand the extension and skip CRL
> checking.
>     >>
>     >> But maybe this is to overcomplicate things.
>     >>
>     >> /Stefan
>     >>
>     >>
>     >>
>     >>
>     >> On 2018-03-27, 17:50, "Spasm on behalf of Stephen Farrell" <spasm-
> bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:
>     >>
>     >>
>     >>
>     >>   On 27/03/18 16:44, Russ Housley wrote:
>     >>> Trimming the distribution to the LAMPS mail list ...
>     >>>
>     >>> RFC 3281 includes the definition of noRevAvail certificate extension.  It is
> defined in X.509, and the definition is repeated in RFC 3281, Section 4.3.6.
>     >>>
>     >>> If the CA is not going to publish revocation information about the
> certificate, I think we should include this extension to tell relying parties not to
> bother looking for it.
>     >>
>     >>   Makes sense to me too.  It's non-critical so shouldn't
>     >>   break anything.
>     >>
>     >>   S.
>     >>
>     >>>
>     >>> Russ
>     >>>
>     >>>
>     >>>> On Mar 21, 2018, at 9:08 AM, Dr. Pala <director@openca.org> wrote:
>     >>>>
>     >>>> Hi all,
>     >>>>
>     >>>> unfortunately I missed the sec-dispatch session, but I have some
> important considerations about the document. In general, short-lived
> certificates have been around for many years and for many different
> applications (nothing new here), however nobody who have been working with
> PKI long enough would actually made the case that the security levels of short-
> lived-no-revo and any-lived-plus-revo are the same (which seems the life-motif
> of the presentation and the document itself).
>     >>>>
>     >>>> Other aspects that I think shall be revisited are the lack of
> considerations about the usability of deployed infrastructures (when no
> revocation is assumed) and some wrong considerations in the document about
> validity periods of OCSP Responses and CRLs (that clearly undermine the
> equivalence claim).
>     >>>> Equivalence of Short-Lived w/out Rev Support and Any-Lived w/ Rev
> Support
>     >>>> The statements that made me jump on my seat is the claim that short-
> lived certificates without revocation support (BTW, short-lived does not
> necessarily exclude revocation support) and certificates (short-lived or not) vs.
> any-lived certificates with revocation support have the same level of security as
> long as the validity period of the short-lived ones is equal or shorter than CRLs
> or OCSP validity. I find this quite a puzzling statement. For once, there should
> be considerations about the fact that if a key is compromised and it is used by a
> malicious entity to attack/disrupt/etc. another entity, the rightful owner of the
> certificate does not have any possibility to prove that someone else did it -
> there is no authenticated trail (OCSP response or CRL) that can be used in this
> case and this can lead, in some environments, to legal implications. I am
> curious about how do the authors address this point, maybe some
> considerations shall be made here.
>     >>>>
>     >>>> Also the claim that:
>     >>>>
>     >>>> " it is hard to justify why the CA or a delegate needs to both sign blob-1
> (the certificate) and also sign blob-2 (the CRL or OCSP response) to tell relying
> parties that blob-1 is still valid."
>     >>>>
>     >>>> is quite curious and, I might say, misleading. Although the revocation
> status (either in the form of an OCSP or CRL) does not provide additional
> information besides the validity when the certificate is not revoked, it does
> provide quite a lot of useful information when the certificate is revoked (e.g.,
> when a compromised happened, the reason for revocation - e.g., key
> compromise, a person has left the organization, a HW token is broken, etc.). I
> would prefer the authors to explain what they mean in more extensive and
> engineering-appropriate form. This is another evidence that the two systems
> are definitely NOT equivalent from a security perspective.
>     >>>>
>     >>>> Another example about the fact that some form of revocation is still
> needed comes from the document itself (thus contradicting, IMO, the main
> claim of the document - 5.1):
>     >>>>
>     >>>> "No matter how short-term these short term certificates are, there is a
> certain window of time when the attacker can use the certificate.  This can
> often be mitigated with application-level measures."
>     >>>>
>     >>>> this is "application-level measures == application-level revocation". This
> means that now, instead of having standardized ways to check for the status of
> certificates, each application need to implement a way to deal with it on an ad-
> hoc basis and being able to distribute securely this information to all relying
> parties. Undoubtedly, for anybody who has ever had to deal with such
> problems this becomes a quite costly and intractable problems very quickly.
> Maybe some considerations about this should be added in the document as
> well.
>     >>>>
>     >>>> Usability of Deployed Infrastructures
>     >>>>
>     >>>> One important section that is missing is: how do these no-revocation
> PKIs look like? There are basically two main choices here:
>     >>>>
>     >>>> Deploy a 2 level-only PKI. That means having a Trust Anchor that issues
> directly the EE certificates. Besides all security considerations about TAs being
> online (as required in short-lived environments), this makes it very difficult to
> deploy. Important considerations should be made in this case.
>     >>>>
>     >>>> Deploy a 3+ level PKIs (current best practices). This approach involves
> having (usually one) intermediate CAs (there can be more). In this case, the TAs
> issue the intermediate CAs' certificates and the last intermediate CAs issue the
> EE ones. Obviously, intermediate CAs can not have the same short validity
> period as the EE certs, therefore the need for revocation (at least at the
> intermediate CAs level) is evident. Important considerations shall be made also
> in this case.
>     >>>> Wrong Considerations about CRLs and OCSP Responses validity periods
>     >>>>
>     >>>> In the document, statements like the following shall be fixed and
> expanded for clarity:
>     >>>>
>     >>>> "If a CRL has a nextUpdate field that is 4 days in the future, a typical
> system will not attempt to fetch a new one before those 4 days have elapsed."
>     >>>>
>     >>>> And then it continue by stating the following:
>     >>>> "For this reason, moving to STAR certificates provides a similar level of
> security to what is generally practiced on the web."
>     >>>>
>     >>>> Since the first statement is incomplete and, thus, misleading - the
> second statement does not hold. Let me explain further for the people that are
> not familiar with how CRLs and OCSP are processed. Although there is a validity
> period for revocation information, it is well-known that the expiration field
> indicates the time "within a new revocation status information will be made
> available" and it is NOT "this is the revocation status of the target certificate
> until the expiration" - common practice is that when a revocation event occurs,
> new CRLs and OCSP responses for the revoked certificates are made available
> immediately or within few hours at most.
>     >>>> It is an important distinction that highlights also why the lack of
> revocation information makes the system less secure. Although it is quite
> evident why and since this is not addressed in the document, it might be useful
> to spell it out.
>     >>>>
>     >>>> In a multi-party environment, different applications might have (a)
> different strategies when it comes to caching of the revocation information
> and/or (b) check the revocation information at different times. Let's make the
> case of 2 parties checking the rev info for the same certificate. If party A
> accesses OCSP/CRLs at {time1} and caches it until {time1 + delta}, party B
> retrieves it at {time2} and caches it until {time2+delta}. Let's assume that time2
> > time1 and that new revocation status information is already available at
> {time2}. This means that, although party A is still vulnerable until {time1+delta},
> party B is not. In a short-lived cert environment w/out revocation ALL parties
> are VULNERABLE until the compromised {key+certificate} expires.
>     >>>>
>     >>>> It seems quite clear that the two environments (short-lived w/ no revo
> and any-lived w/ revo) do not have the same security properties.
>     >>>>
>     >>>> Therefore I think that the authors ought to demonstrate the
> equivalence of security levels (not just assume it as hypothesis - given I just
> disproved it) or to remove all claims that the two environments are actually
> equivalent from as security perspective and to add specific considerations for
> short-lived-no-revo about the the fact that not supporting revocation is
> inherently weaker because it potentially exposes all parties to attacks (e.g.,
> MITM, un-authorized access to resources, etc.) that can not be stopped (unless
> you implement application-level revocation.. and, therefore, re-introduce
> revocation from the backdoor in a non-standardized, ad-hoc, hard-to-manage
> across application fashion).
>     >>>>
>     >>>> Final Considerations
>     >>>>
>     >>>> I am not opposed at the concept of this document to be considered for
> BCP, however all the above issues MUST, IMO, be addressed before the
> document can be considered further. I think I already raised these
> considerations at the last IETF, but I do not think the authors missed or have
> not considered the provided feedback. I hope that a more explicit and written
> feedback might be taken into considerations.
>     >>>>
>     >>>> Just my 2 cents form an old barnacle... :D
>     >>>>
>     >>>> Cheers,
>     >>>> Max
>     >>>> --
>     >>>> Best Regards,
>     >>>> Massimiliano Pala, Ph.D.
>     >>>> OpenCA Labs Director
>     >>>> <cndojoacigamfbdj.png>
>     >>>> _______________________________________________
>     >>>> Spasm mailing list
>     >>>> Spasm@ietf.org
>     >>>> https://www.ietf.org/mailman/listinfo/spasm
>     >>>
>     >>>
>     >>>
>     >>>
>     >>> _______________________________________________
>     >>> Spasm mailing list
>     >>> Spasm@ietf.org
>     >>> https://www.ietf.org/mailman/listinfo/spasm
>     >>>
>     >>   _______________________________________________
>     >>   Spasm mailing list
>     >>   Spasm@ietf.org
>     >>   https://www.ietf.org/mailman/listinfo/spasm
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> Spasm mailing list
>     >> Spasm@ietf.org
>     >> https://www.ietf.org/mailman/listinfo/spasm
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > Spasm mailing list
>     > Spasm@ietf.org
>     > https://www.ietf.org/mailman/listinfo/spasm
> 
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm