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

Stephen Kent <stkent@verizon.net> Thu, 14 May 2020 18:13 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 77EA13A0B0C for <sidrops@ietfa.amsl.com>; Thu, 14 May 2020 11:13:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 vjgk1C_XHfiy for <sidrops@ietfa.amsl.com>; Thu, 14 May 2020 11:13:57 -0700 (PDT)
Received: from sonic317-26.consmr.mail.bf2.yahoo.com (sonic317-26.consmr.mail.bf2.yahoo.com [74.6.129.81]) (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 195223A0766 for <sidrops@ietf.org>; Thu, 14 May 2020 11:13:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1589480036; bh=DMxfkgggEahhx1oQnYLvFCr9rbonzYuf+w1ku1LkeQc=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=QdZX+kl2IAHXN1xslN0FZ98uW3eKBMH6hSwL0dag85VVEst5OZG9hUNBDUgV70hT8ewYjljolrRHFx8+f7KTdrNZ3BfbJk++lHazDMooQPPhPF/+Bk1MkW2ZC7LcBXmy7iHTCu8HZZegJQ+Cc6lXUL4vmFj41bxwQl962UkbSP1VFMjWSrfn4I8+fIgyGR3AYR3kdmUCZASQpSGHu14FyLmodx0vX96qU3/mmVPFfGE1RsROM966h/58Z2+QYibS0+K7QTWb+84JfrEzNYJ+w4sYu5Dichds4eCNfnBm1BVOQx3Q5DQ0bFzUV/BpGPCxofvYPwynMDqs0EAxl2cuaQ==
X-YMail-OSG: SZbzRaoVM1koxq_8u.jQUv1kR9g43cDW3NclZDGi.r87rjx3RIA4HsG.S1575iR VJ0MLi0UuJiYdEqkJbztdDUvkQILRtQUz995peDYMfJmiNe86rZAYIuvi050yepHw3zJwudmKdTu wActXTptzUy8YyEZrJ6f3W8uQes3knnp_DSbOX6D_g7Zs0lDnrIlseKy_CUjlq7jaQzetsdfzjTZ eYeaJaWdhzxlLaSQdWfaLinRnGze4d4EHVaYSD8j9qSq49Tmq44H.xMguh6P4J8RSQPrcKcOji_8 A9AHQe4PoOj8xXoll9MhwxwCzvMyVWPdU1q3YBdhiT_rwNlBGPsxVrXut8zAk_EBSJhmZmYtDuk8 H2K57vxLlTI.ZwuH0u4awBXB8KqZ9yGVQWG6hXUl2eC4nB1MjyZE9FYECbzBLmPHJVjO3VD4VlWb s.JDiZJjtRCj1osxb.m37Br_SU2oKGFhLe5gVmU8XLE6GgfHKJK15iZiRQmW4NWqZO9CPtojq5EH 6zQiIi5IarluiEYRTzU9JUkUWi27.t_OxXg2Dz57hMofsC3n2.wk_X2LzYUMb8NRuyDFU2C9KtO9 .6ibJ.i1mA5zNDc7vFx1120ZZBUGGn8.1LLKuqLQsB0JmN9Mfof5uWFYj_RgCo6O.YXuyu2gZIU3 j98butsrYxGH7mdqDQ5_L3ePdW47slz9wZuZ1r1jqDQW1OeA_RBPTeW5FVRgcfdEfpr1ksFG57sD xV2MtjD71d4YxOel6hWr26W0voYf2FB_xQxEcYMHeR6TMysmRYDBp7o2C3JX6VF8jw4q1OMC2YP9 dAq6XruE.WXj6AI38iXkjv0Au89eRHu_vTUTDB0uvDIXyjIgttDBDldi8tySDEBkn6yiWIuMLEzP Z6OPPLrsQDtfzu3rY0OIpoKkqhACpAvvGaQSielhSG7BEg0g8TDWvLTrpV3GkU_BYTKC_XoVFYcp LfewfvGweOwup1tw2po1odMpAw2MUQxg41eoN9DBt1ZDSspLP3WaPv7eucZFvW5XDC8BXfwCfNBQ BQCyBxdixJB78YUq4uNxHk0SVPtvzTxpkOckvUb9_qF6FxEt11f.m_AGN7dakN6T3r15KmP7NKPK BA.0IQaBgxn5MLVjfX7Q7Y17mns7ODh3y3NnYd6iV1EOSC7KBqRKuLfcbtF64Gv3mO_6iTHlCSp_ VDEsRMkEvY5rBOewH5WDoctzCkM6b9Un10Ckzc6kIxwvSyRLX_WcIWhuhnEpBWWUx215p31g_38b 4avCu29XbARSf2x4y08GxPN0jQVHkgAqj6e7U67lfR67IJI128Qvd7tk688efdVGBggxX6fQQEUY j132qMz66cinG.eBKWdxVzoy3qMJCtOWfBXmgSfR6g5s0y8YtBWGAgEKXVPrwjuMk8P7J4L7LP4o GpaCMv2t5BbGHDm6UGMz5SukqIYagOTAQslErIid1ExOVrX57Kev4
Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Thu, 14 May 2020 18:13:56 +0000
Received: by smtp403.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 34645cecae602f4a58ab7b7e7342451a; Thu, 14 May 2020 18:13:52 +0000 (UTC)
To: 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>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net>
Date: Thu, 14 May 2020 14:13:48 -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: <C49A008F-02FE-4A97-9E96-5EAAFBA5AC48@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15941 hermes_aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/o39lf3Ds7-MRRPPltcDXT46SbQ8>
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: Thu, 14 May 2020 18:13:59 -0000

Tim,
> ...
> What may not have been clear from my earlier message is that I agree that in today's world it's worth supporting the possibility of more than one .crl like Rob A. has done.
>
> That said, we are looking to improve things here, and reducing corner cases is good.
>
> This is about the number of current .crl files on a manifest, not about files that may still linger in the repository under the directory - e.g. for other keys.
I agree that the focus of this discussion is files listed on a specific 
manifest. If a CA has a different key, and thus a different cert, the 
CRL issued under that key will be on a different manifest, and thus is 
not part of the concern here.
> Even if it is not explicit, RFC 6480 certainly points at having one CRL per keypair. And 6 out of 6 independent CA implementations have done exactly that. Therefore I think it would be perfectly safe to add a requirement in the MFT RFC update that there MUST be one CRL only. This will simplify things greatly for RPs.
One CRL per manifest is my goal as well.
> 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.

Steve