Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Stephen Kent <stkent@verizon.net> Tue, 19 May 2020 23:43 UTC

Return-Path: <stkent@verizon.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855E53A041D for <sidrops@ietfa.amsl.com>; Tue, 19 May 2020 16:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 ns6bX5JN4YaL for <sidrops@ietfa.amsl.com>; Tue, 19 May 2020 16:43:04 -0700 (PDT)
Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E4033A041A for <sidrops@ietf.org>; Tue, 19 May 2020 16:43:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1589931783; bh=ptBULF6mRl4w7twYqqbCNJV10YrL9mhIEpEgZB6ae84=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=auuuj4t1YZ6FgFypfNZjdhatkghFVjE8Lpk/OCIQggkJu43askyG9Hc9wOjjnPZaOMzurgMakPf++T126Bk80nBa83pOYgSJs336d6ZIlLMF4y+MNVsSW4nrw2MFqb8GDT3iAT4Wfz76I/fSa7ba2WtfbPBYlCLNxJ1HOT0eL+LObtBic4rTKxQ/wUtouB2lOMbXWXC0+oKQebZ+WHW3o14HZxJuIQB65uSq56zyTtIYtYpTsQkblZAG7B6OgHEO32PX59xXRy2XOzzgF3z2M4I6OeNNFrvS+m46RYWS0SiHgDuw5rzXRve6Ni97HQQYLNyJi1P5KRiwPi1lId/ZhQ==
X-YMail-OSG: xvMRQlQVM1lhhD1ihFmSs7EdQtHYMYhSYGATYCi35t218EDdsNR0c0JwL4roqVm A69JTlJJlq5w36lqKGQ4CshJ2ImwEA317vs7K6Wn5tCnuiha3pFC487xjzqRYrmYCmD7JTtt4LSY TPOD_1cy1rnLQrDRlQ2z.ksZtYKw2OU1Crhrw.y10MDjICtQocA6RMy1qY2DyBLdBWFkO.qjjsgc JyvanzE9zCswNrXC9DIAlORL2NQSiFvlyAz3UkhKTieBt1yFq6WggsNwgtp9gu_VgpdCHyoyjHkq 8II6h5fn7sL916K4cp1AwG12X.xJXgc_YHsMPmPk8c7QU.a6KkG020OevvkcF58XWr5kVLMFfjyV OUWD.5lwiYRv4c1vC8HSMASb.mfuZaGeqIfigN7Vg9e_toZ_f7RPFppNNJJHY.C9uUgtWx0Pvfn0 k_yhcG.aJNpAq9CzROxfW4eirgY6_snBKIKI05K4ZKa0UrIW7zmSxlrCTkzryhvDOcZqd4SmV_mn U6J7OdwihjDwVM5l41b0zNrRHSVaJKJJR5_zw0umu5YBH.7gcaLSAqajme5zZY9vRYHoSe_eLsMw 3B6r9zPn8VRm39LQfiddBGbTKwC_BziC_qJB0_u1snMfkEeNhSsGIejvkCKu7ZfyhXU0BeJOo2Qz 1x4pLc_o8mgs_FBuBj60MR6we6cxzEuBHscKaTgxCBd2DJ.DEM1PcsvjecXcYEc.1H1v54Rq_aEf jHwWCt61W9QYlaK5IC6MmbdKsT2lsIAPcFvWACGuxMXNRVxB8_cYUahhPL9h9zcVjPAWA4_F4IDy HHibv_8Md6ZqEc7DNy94O3vkHOteuW63vWJOYo_mA8bm8bxSXX8RNktaFCzbnT4IcI9gGO8K.8pE CcXP7zhJEMtMtVsDLDIhsEtRmx4YqavVRXmo92R22Sec78uwLk80OhunlnNFXLsx0wDyBeVMtxP3 02b7bSrdRdPihTnUk0Z4Rex5.B6Q_EcstQgptbeMtxr38S6hom9FwmH9ck9mQF764sEaVecVj8dH 69ShhSfhXv5wITTe6YqvEPvx2jRmDB8ub89RNZa6KOOsfzAyWmdfMBYlF6LlI6TY8.2qjPsbhJMu NmiTy9fvhC_zOLukLId5YXC.xKFkbp9rJ.dY4yaG0pR8_Y2LlmG2J8oeA7xZW_n6hbYs.u.NQAwX rYxUM6X3dbBuOo5DROJqWh7CHS0sIIazRvM8Rbg4tA_JpYL4eWGkMxh8MINnzRYvb6SidGmn3S8a kd00fzQxo7_YV.EUTVvsa2cOg9WuQCaCKcoo.JhF_D8Ke7IfiyJ4s.8iTG3s50fWUj9m5xmkoODF mZQGKNGg3X9b2kWCMqJ5v2iA9TBFaz.ihltdsCcrkeOsufQEog7tVLiplmk083675ejGvJyxOLd2 SZB.PVhQQjZJ29cL_8cc7Kl68
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Tue, 19 May 2020 23:43:03 +0000
Received: by smtp418.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 65da7e6560ec3cb402ee12a3d9ed9cda; Tue, 19 May 2020 23:42:57 +0000 (UTC)
To: Martin Hoffmann <martin@opennetlabs.com>
Cc: sidrops@ietf.org
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net> <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net> <m2imh0x750.wl-randy@psg.com> <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net> <C49A008F-02FE-4A97-9E96-5EAAFBA5AC48@nlnetlabs.nl> <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net> <20200515090840.12a9464a@grisu.home.partim.org>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <97899f4b-a10e-9e78-2fc7-3984b0a155f2@verizon.net>
Date: Tue, 19 May 2020 19:42:56 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200515090840.12a9464a@grisu.home.partim.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15960 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/F8OceF3ThJd8eMyKBiqxDkvIL-U>
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2020 23:43:06 -0000

Martin,
> Stephen Kent wrote:
>> Tim,
>>
>>> If not, then indeed we need to have a discussion about how to deal
>>> properly with multiple CRLS. E.g. do you check *all* of them for
>>> each issued certificate, or do you only check the CRL matching the
>>> CRLDP of that certificate? I would also be very curious to know
>>> which use case warrants having this complexity.
>> My suggestion is the KISS approach - first .crl file that has a valid
>> hash is the one to use, and others are ignored. That's less forgiving
>> than what Rob accommodates, but being forgiving here might take
>> pressure of a CA to do its job properly.
> I’m not sure it really does. Rather, it will lead to strange looking
> issues: If the wrong CRL accidentally made it onto the manifest and it
> comes first, all objects are invalid even though everything sort of
> looks fine. This may even come and go if a CA reorders the CRLs when
> it reissues the manifest[0]. If all CRLs are referenced by objects, some
> objects suddenly are invalid while others aren’t.
>
> I think invalidating the manifest with a clear warning is the more
> straightforward approach and much easier to debug.
>
> Kind regards,
> Martin
>
> [0] That may happen if it is file system based and just adds files as
>      they appear when reading the directory without sorting the file
>      names first.

I'm not sure what to make of your message.

I don 't see a specific proposal here.

Steve