Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL
"Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com> Wed, 13 October 2021 16:12 UTC
Return-Path: <hendrik.brockhaus@siemens.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 EFD1C3A0BDB for <spasm@ietfa.amsl.com>; Wed, 13 Oct 2021 09:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.797
X-Spam-Level:
X-Spam-Status: No, score=-1.797 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.onmicrosoft.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 dP69RpRe33zX for <spasm@ietfa.amsl.com>; Wed, 13 Oct 2021 09:12:45 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on062d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::62d]) (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 91BD83A0BDA for <spasm@ietf.org>; Wed, 13 Oct 2021 09:12:44 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ofbUNO1pasuHWyLhn49268EF+nYuKLKBXDDanBxvgxnsB0l/fISfs+W0/9RRMIBPPCecK3pu2VSk1DWx8XmVmrudtTxy4B4hgi2rbG+AA4XckPonnEyjteJWWX10PiMzR4ZINghU0j+c1DRpGNhJJZcWuIi3AxB0OLRN17I0GGOZhfQq0hUT3/58dIJYRCjnYOfFtAJYxo/k2sPF6qm7na0yUxvl0Vej4wJUnOI0rMkB7+JRNEjAb27ZQpozbOl5IHabvkIeiwvjyByLf0CCl+5zO98WLpsmtfUhwPs/OL0z4EAOurGni0nDiA2AL8UHb8tgiNaOCGXE7ggJc2YqrA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IGqRbwGRdCTE7rXs5VJmei/owm/Jaqvj5MSWXZJ54Nw=; b=lG6/zFllX5X6+c6y+zJUP96jBlyp8ahQyDp6IUFZKCanjYqOdqnoyO18/MtreRzosOaX+6cNGW+dPBiPuD5inXUyYUu4IVTNuD5Ng78kZqMCXdQz2Pp1IASrphvYXBbNqtnllUBnqWZkDu3CwbGwujOodFmHwXxdt2McSFQ0a+jVzuQOyLbPmnfpDdYfB65Qo5BIiypHdqizSUfZdGle9Ocd3Vof7mWrtLOdG3hrMlzK875bc/d8Ereze1genC7F+xlGOj1i/roI7G9bnbkNi86Y8O/Px4oczRAEDikix+bKnJWoTFuJMeXEZMqBHsIA4FM9HAn2HENbIiZCfNbZCg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IGqRbwGRdCTE7rXs5VJmei/owm/Jaqvj5MSWXZJ54Nw=; b=NFpssrtn4GWF6by1FobH2QwRRi06RnZG904Fc6cmtz6FHo7K4XNp/IXC9dixwdvtEl/MRA1J38hlf/pEvinS316pNcwTKX6X2mxpzzO6E0CCK1jHDTvAXwL2GX1g7PaSK8o46ipMG75BzesK2Ldqxu61cB6fIEyPSKTqzwU/Sr0=
Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:7e::24) by VI1PR10MB2430.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:803:8a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.24; Wed, 13 Oct 2021 16:12:32 +0000
Received: from VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::1c2e:9e94:8071:b1e2]) by VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM ([fe80::1c2e:9e94:8071:b1e2%6]) with mapi id 15.20.4587.026; Wed, 13 Oct 2021 16:12:32 +0000
From: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
To: Russ Housley <housley@vigilsec.com>
CC: Lijun Liao <lijun.liao@gmail.com>, John Gray <John.Gray@entrust.com>, LAMPS WG <spasm@ietf.org>, "david.von.oheimb@siemens.com" <david.von.oheimb@siemens.com>
Thread-Topic: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL
Thread-Index: AQHXvICw5lKlXeFImkiFFvAECAJpoqvLCKYAgAJP4sCAAJR6gIAAAnsAgAAOYZCAAB/HAIAAFQeAgAAFdYCAANCAAIAAWWfAgABMlgCAAVwQAIAADpnwgAAGyICAAABBAA==
Date: Wed, 13 Oct 2021 16:12:32 +0000
Message-ID: <VI1PR10MB2429F01B2A8A4ED619617609FEB79@VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM>
References: <AM0PR10MB24181E0CB7F13C5969337F56FEB09@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <EDA2ACBF-E745-430A-A13F-A144B08125AC@vigilsec.com> <AM0PR10MB241887D39072B393C56FB28AFEB29@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <8D6D333A-14A3-4487-967F-CFCAC22D856C@vigilsec.com> <AM0PR10MB241865E9784CC03F81AA9D39FEB29@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <B92F36D2-605F-4E60-A654-AA0F89E310CA@vigilsec.com> <CANNx7D8AaT3+7Ah7tZHXUYRkcgx7CW_ExgciJ4nB90WAuP6tzw@mail.gmail.com> <E5F845E3-4281-4409-9085-28CC68751DB3@vigilsec.com> <AM0PR10MB241822FCF1E83E6444FDFAE5FEB59@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <0b24c287-a6ac-593e-e0e4-3fd0b9373208@von-Oheimb.de> <B48AB092-BE17-42AE-BBA8-7ACDBDBF75D7@vigilsec.com> <AM0PR10MB2418B4A2D6498C6E4A7CC6D9FEB59@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <C5546F9B-8AF0-48FA-9B9E-FE10C9B700F9@vigilsec.com> <CANNx7D-y4Sju8DN8=AmOQnq+GhrPAbmgZnhwYoDoSy_iB6gfpQ@mail.gmail.com> <29024D4D-A638-44AA-855A-6081F66D4A24@vigilsec.com> <93dd2d1d-3e82-36de-280a-365d3b1c388c@von-Oheimb.de> <AM0PR10MB2418F810110FDE2E11BCF8BBFEB69@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <DM6PR11MB2585CC2BC632716E78587668EAB69@DM6PR11MB2585.namprd11.prod.outlook.com> <4B13DEB3-A384-4559-8AF2-4ECCDDC4ED7F@vigilsec.com> <VI1PR10MB2429045512EF000D0ADA8B64FEB79@VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM> <4221E1CA-7345-4DA2-BBA9-3B52C1102690@vigilsec.com>
In-Reply-To: <4221E1CA-7345-4DA2-BBA9-3B52C1102690@vigilsec.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-10-13T16:12:30Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=b44bee56-b48d-46c2-9a03-4406da8f1d3f; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: vigilsec.com; dkim=none (message not signed) header.d=none;vigilsec.com; dmarc=none action=none header.from=siemens.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e2a4c196-f74b-4aaa-bc3a-08d98e64431c
x-ms-traffictypediagnostic: VI1PR10MB2430:
x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <VI1PR10MB2430EF69E4F0AD7E767A186DFEB79@VI1PR10MB2430.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: rnmWvxOnpcgXwdY6WOq++6OjmI1leXijKRaRT3R0r5KcMvpAJ26IBNdqWDuaCT8NkWpDliaMvU3PV0h70R50FRtdHAQVL+XGWmAGzr2z1wUmpFG9f4aZSKfMkUvbAHtPPnEe1vBoE8YpCVCIba/2xXi7+VKG0LCIpZUmNEizl0Uks0YxYYuVgjgfBP/d0PlFOPDBEWb5QGV3FtNXP3SQeh2q0J/P5JFXrozhJF6RWC2IbG5bIkq0WI+Qgf7oi8soEAjjpGlcYbrU9K6CI6dr+YKT93n48vqtTlv5xkiklPnb2Yyu/M1exgOUggSS/Wnls9Sr/0RXbqI6HuVpMUw5Wud+g09O3a8yIXDHQDvTUhR5INGgHrlF23H+LlGvRDDVYjCQML5CXKDzUU7us5yhyQ8sWquGXb9tjHn0aA2w6bOzieym92nDYmU0CYCRSYdNdguoZLWt1OYfJU/rsfNtokN9v1Rcp9KfIDigZrQGvR8ZRFXPxfF83bKuT1iOFOmwHPpTte3rLHDANV/k63Bi/lbiGrsonCY6dbFIFx+6VXsgDVNGoVjWDZX3tbu3m/3Lgo52wc24zTcSDf5NKtLRT4knGBH8B5IBovskkLvSuv1q5kf4OtIjbOpOUFxSSquDK1xOOEEFrf6Zi51WPjBFSY/ZpJUjDWJVsNX31X84jxlWZVXwLUKRQUH6q09i7v38s5iXAgaWOI8+bzoVhB9+ErRkJ7LI6Fedve4mP7Gx/w1mhiDx14ymWed5OH714AGthfJ/b5y4MDdTewAUJbA4DgoKpdXNBaC1nbprki5y/GXvdb2stYCUxPyK8rlgHXsM4X4TTzk8bdJC12+IEnlMkjyoK9O0sEizvI0O4ZPWuqQ=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(54906003)(83380400001)(15650500001)(66556008)(53546011)(166002)(76116006)(66476007)(8676002)(86362001)(66446008)(52536014)(966005)(4326008)(55016002)(30864003)(66946007)(6506007)(9686003)(122000001)(38070700005)(38100700002)(64756008)(71200400001)(8936002)(33656002)(316002)(186003)(6916009)(5660300002)(2906002)(7696005)(26005)(508600001)(82960400001)(107886003)(403724002)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: /Cxk4IwrH4mk1Jx2jVU8iP8XEkF/OAl7Hrp7vViWJ7cZwldwdeOkCKNcT9gCLAX/yHJz32uhjZWeQn6dTz4ePf8nYMxrH2HQ3f/lV/CiUpDgBZNj/cxfq5wjIpXfA+Fz06pfG/clGvqNpi6v2CuTV6p/8NcJcyOf8Wvq12T8d/GALHUuotlUJrAeWlz3nXjbPTLal/SZ7SZuN7AfZwqIuKIQ/eu3bsnQNPwkI2PNz/9/L8y92KXFwLP8F72b+Uh0sUpFndN/+v2sGGxTs3jt/wTNmCOEHy8cDayZKSK9omJr6hwX1db+vznadPtaCrenRYW1KuwTapBfETU4OrTe96yC5DOAbJF4GeYnSTiXc25RujfUPbFbuAUHgXmg/3pVIbSbSm5mqbGxxTlfV7avhmS96aOzJPMQPFbChUN/nxU6QtdTzK9BkJzixk2n7f0frsHPC3pThsuuy8y7iQACXUWNmO+hgVffE70BvYtAEQczPbisPpsM00K8Bp8+j7wS9neGsg3vpvKjwM2CFd8VRhtm6seC7+eL3UsdUgklF60mjz+e9wTEdQxsfbJRwQkPIHsdYkJ1RmkgeeNKe0STdEJrjW+6NlSfOBFmn3LvwVB8BzJJMQUdutCtM8jbAmSNVJdfZ+WL3YtFOJIu4ebxDumyjYLkQoFY0wiifS+MsGzIXKRyD2IWJrBQ8aC7I72p8CN6GbrvGOk54ngY6ePctXgep9lUV+a+N338lLUdxN0c6mxAa52YVuOxs8gwtDYLiFv8X3IhiC3py8eGqSsrNUVC0DhsS+yIRjLomqHSMYkYpve+NeuU+RbC95DhPtIN+kMilZwe6qMH5ZlsceS+6G5pJohms12zlbq8N9YrlMX/+S/QgyKADd/9LF+mJn9exPuGsT6GJ4l3t1MCY9c3c7LgjjP/GLk1mDHCFhY/9XK34rEls3BoEs2658qM67k+mZmLqhm3WB8e+VvAw5zA32CnOIIldisO1pCmWGlbHV3i0P+jQ8vBJCLc8v3/rPNL7Sqb3M7gkPpIb8+phAsYrYvFdJrKGPmp5hygRuMFLYvEBy1C6DUZ2ukFWzOJk9NG30C9uP6YOefLtELvldfbCEDCyqTSsQ02eisLkBRmoWgCrR3JkRUA1Wot1luaod8eyXIR8x3Jr13nYPCij4Vo6R9ZzvLDIHoHrEF1ScFqkrsLQQewqBsKUzdD8dwPRDb2ihKMzoT8KwAwDDSHIGVUkpNuo5m3FzrdjDZzLw7+63U5cg8WfcxExHsUcBwt/N1856GRCySrue3uQubh1M33PUC/tA4oj0ZdWXEVzTLSEK3pvZUKkyPBz+L0rE12jZPy
Content-Type: multipart/alternative; boundary="_000_VI1PR10MB2429F01B2A8A4ED619617609FEB79VI1PR10MB2429EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR10MB2429.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: e2a4c196-f74b-4aaa-bc3a-08d98e64431c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 16:12:32.0348 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: u+17HksBHJ1DvjYcJlTMJDU7WeeQrDOryFcdQ+a4rIUArRAQZuOXEy9f2hpEzmBadMNGfm2eEfSg7NZtPXCVgsIWDS/A1fIqDyE6Sl/diIY=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR10MB2430
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/NWuwi4lJyPlGdWCEDTxulcKPZ6g>
Subject: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 Oct 2021 16:12:50 -0000
This is definitely easier to read :-) Hendrik Von: Russ Housley <housley@vigilsec.com> Gesendet: Mittwoch, 13. Oktober 2021 18:08 This is a nit, but I think it is more readable ... CRLSource ::= CHOICE { dpn [0] DistributionPointName, issuer [1] GeneralNames } CRLStatus ::= SEQUENCE { source CRLSource, thisUpdate Time } Russ On Oct 13, 2021, at 12:02 PM, Brockhaus, Hendrik <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>> wrote: Russ Thank you for this suggestion. I like it. While you were sending that email John, David and I were having a meeting discussing the different scenarios we would like to cover. We see theses two situations: * The client knows a crldpn from its configuration or from a certificates CRLDistributionPoints field. It can use this for all the special cases like Delta CRLs, Indirect CRLs, etc. * If no crldpn is available, the client will know the CA that issues the CRL and would like to get a full CRL covering all certificates issued by this CA. There are also two additional situations: * The client already has a CRL and knows its thisUpdate time. * The client does not so fare has any CRL from a specific crldpn or CA and therefore does not know any thisUpdate Time. To be able to also address these situations we suggest his syntax: CRLStatus ::= SEQUENCE { crlSource CHOICE { crldpn [0] DistributionPointName, crlIssuer [1] GeneralNames }, thisUpdate Time OPTIONAL } id-it-crlStatusList OBJECT IDENTIFIER ::= {id-it TBD1} CRLStatusList ::= SEQUENCE SIZE (1..MAX) OF CRLStatus id-it-crls OBJECT IDENTIFIER ::= {id-it TBD2} CRLs ::= SEQUENCE OF CertificateList GenMsg: {id-it TBD1}, CRLStatusList GenRep: {id-it TBD2}, CRLs | < absent > We also discussed if CRLNumber, but we did not find a case where thisUpdate and a reference to a concrete CRL source is not precise enough. Hendrik Von: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> Gesendet: Mittwoch, 13. Oktober 2021 16:52 RFC 5280 defines CRLNumber, and it does not allow negative INTEGER values. So, I suggest: CRLStatusList ::= SEQUENCE OF CRLStatus CRLStatus ::= SEQUENCE { crldpn DistributionPointName, crlnum CRLNumber, thisUpdate Time } CRLs ::= SEQUENCE OF CertificateList GenMsg: {id-it TBD}, CRLStatusList GenRep: {id-it TBD}, CRLs | < absent > Russ On Oct 12, 2021, at 2:06 PM, John Gray <John.Gray=40entrust.com@dmarc.ietf.org<mailto:John.Gray=40entrust.com@dmarc.ietf.org>> wrote: I think we should only need the DistributionPointName, as we need a way to give the CA the information it needs to be able to lookup the CRL from its internal list of issued CRL's. I hope this should be enough information for a CA to distinguish which CRL is being requested. Is this an assumption we should be able to make (that a CA would easily be able to determine a CRL by its DistributionPointName)? IssuingDistributionPoint ::= SEQUENCE { distributionPoint [0] DistributionPointName OPTIONAL, onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE, onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } DistributionPointName ::= CHOICE { fullName [0] GeneralNames, nameRelativeToCRLIssuer [1] RelativeDistinguishedName } So is this good enough? CRLStatus ::= SEQUENCE { crldpn DistributionPointName, cRLNumber INTEGER, thisUpdate Time } In David's (2): CRLStatus ::= SEQUENCE { issuer Name, cRLNumber INTEGER, scope IssuingDistributionPoint OPTIONAL } Isn't the Issuer name redundant because we would be making the request to a specific CA (our CMP server), so that should not be needed as we are making a request to the issuer (or an RA acting on behalf of the issuer). ThisUpdate is needed to indicate to the server to only send a CRL that is newer than the given thisUpdate time (otherwise send nothing). This should gains the network efficiency we are looking to achieve. The CRL number is to request specific CRL numbers when all other information is identical. I like Russ's proposal of supporting multiple CRL's in a CRLStatusList as well (at the expense of a little more complexity). Supporting CRLStatusList makes it more flexible in case there is a need to request multiple at once. So I am fine with that flexibility. CRLStatusList ::= SEQUENCE OF CRLStatus CRLs ::= SEQUENCE OF CertificateList GenMsg: {id-it TBD}, CRLStatusList GenRep: {id-it TBD}, CRLs | < absent > Cheers, John Gray From: Brockhaus, Hendrik <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>> Sent: Tuesday, October 12, 2021 9:35 AM To: David von Oheimb <nl0@von-Oheimb.de<mailto:nl0@von-Oheimb.de>>; Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; Lijun Liao <lijun.liao@gmail.com<mailto:lijun.liao@gmail.com>> Cc: LAMPS WG <spasm@ietf.org<mailto:spasm@ietf.org>>; John Gray <John.Gray@entrust.com<mailto:John.Gray@entrust.com>> Subject: AW: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL Do we really need the whole IssuingDistributionPoint, or is the DistributionPointName sufficient? Hendrik Von: Spasm <spasm-bounces@ietf.org<mailto:spasm-bounces@ietf.org>> Im Auftrag von David von Oheimb Gesendet: Dienstag, 12. Oktober 2021 10:12 An: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>>; Lijun Liao <lijun.liao@gmail.com<mailto:lijun.liao@gmail.com>> Cc: LAMPS WG <spasm@ietf.org<mailto:spasm@ietf.org>>; Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>>; John Gray <John.Gray@entrust.com<mailto:John.Gray@entrust.com>> Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL Thanks for the clarifications. So how about adapting the CRLStatus part of Russ' below proposal from CRLStatus ::= SEQUENCE { crldpn DistributionPointName, thisUpdate Time } to (1): CRLStatus ::= SEQUENCE { scope IssuingDistributionPoint OPTIONAL, thisUpdate Time } or to (2): CRLStatus ::= SEQUENCE { issuer Name, cRLNumber INTEGER, scope IssuingDistributionPoint OPTIONAL } ? In this way the full scope information can be given if needed, while for the typical (simple) cases, it should be sufficient to give either the thisUpdate value or the CRL issuer and number. David On 11.10.21 23:42, David von Oheimb wrote: So in the end the whole IssuingDistributionPoint structure determines the scope. David On 11.10.21 21:45, Russ Housley wrote: Lijun: Yes, I agree. That us the reason for crldpn in the syntax that I suggested. Russ On Oct 11, 2021, at 3:26 PM, Lijun Liao <lijun.liao@gmail.com<mailto:lijun.liao@gmail.com>> wrote: The URL specified in the extension CRL DP, should be able to identify the scope. Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> schrieb am Mo., 11. Okt. 2021, 20:11: Hendrik: As the introduction to Section 5 od RFC 5280 says, the scope can be based on "arbitrary local information". Consider the example that I gave in my earlier response, where a CA uses multiple CRL distribution points. One distribution point could be associated with NIST employees located in Boulder and a separate distribution point could be for NIST employees in Gaithersburg. There are certainly other ways to do this, including indirect CRLs, but this is one straightforward approach. Russ On Oct 11, 2021, at 12:20 PM, Brockhaus, Hendrik <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>> wrote: Russ The introduction to Section 5 gives some examples on different scopes. I du understand how to express theses scopes by using the flags David mentioned. * "all certificates issued by CA X" * "all CA certificates issued by CA X" * "all certificates issued by CA X that have been revoked for reasons of key compromise and CA compromise", But I have issues to understand how "all certificates issued to the NIST employees located in Boulder" would be expressed. Can you give an example? Hendrik Von: Russ Housley <housley@vigilsec.com<mailto:housley@vigilsec.com>> Gesendet: Montag, 11. Oktober 2021 17:26 An: David von Oheimb <nl0@von-Oheimb.de<mailto:nl0@von-Oheimb.de>> Cc: Lijun Liao <lijun.liao@gmail.com<mailto:lijun.liao@gmail.com>>; spasm@ietf.org<mailto:spasm@ietf.org>; Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com<mailto:hendrik.brockhaus@siemens.com>>; John Gray <John.Gray@entrust.com<mailto:John.Gray@entrust.com>> Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL David: These flags are clearly part of the scope. The use of CRL distribution points in certificates can be used to divide the population of certificates across many different CRLs. Russ On Oct 11, 2021, at 11:16 AM, David von Oheimb <nl0@von-Oheimb.de<mailto:nl0@von-Oheimb.de>> wrote: Interesting discussion! It looks to me that the currently open issue boils down to uniquely identifying the (latest) CRL information currently known to the client. Even when scoped, indirect, and delta CRLs need to be taken into account, according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.3%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756680209*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DKqGxNtGOOfOJukKWAIWwBhiljMUJMIwKvLEd9zzefcA*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09vCbUq19%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8b2adc7606c34e9eba3408d98e63b1fb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697381120305096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=qvtF5V4a%2B6mLc%2BGJ3bFtGcUD8gpLPRYPFX7L1siYaD4%3D&reserved=0> apparently the following data should be sufficient for unique identification: CRL issuer, scope, and CRL Number, or am I missing something? And how is the scope defined/encoded? I'm having a hard time getting this nailed down from RFC 5280 and other sources, but according to https://datatracker.ietf.org/doc/html/rfc5280#section-5.2.5 <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Feur01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc5280*23section-5.2.5%26data%3D04*7C01*7Chendrik.brockhaus*40siemens.com*7C4ad01b5d9113414a477f08d98d580223*7C38ae3bcd95794fd4addab42e1495d55a*7C1*7C0*7C637696232756690198*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000%26sdata%3DXi1FhU*2BLZ45xBsdwSQPlUPvwF3zIrv0*2F*2FMHy4nr7sm0*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU!!FJ-Y8qCqXTj2!I9hCPwvpYvYsKczRCM_y70-117Xe4Yvw5aB2pzCAZ768NKnbCwz8aaL09sF5N2-s%24&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8b2adc7606c34e9eba3408d98e63b1fb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697381120315091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=L8JRl5eDvhhe8%2B7%2BSMQsVex%2FxR9WVQtmXNTyfKE5FK8%3D&reserved=0>it looks like the scope is the combination of the following fields: onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE, onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE, onlySomeReasons [3] ReasonFlags OPTIONAL, indirectCRL [4] BOOLEAN DEFAULT FALSE, onlyContainsAttributeCerts [5] BOOLEAN DEFAULT FALSE } right? David On 11.10.21 08:28, Brockhaus, Hendrik wrote: Russ Thank you for this proposal. It looks straight forward. I will need to dig a little deeper into the partitioning of CRLs and check the requirements of our use case for CRL retrieval via CMP to better understand the complexity needed. Hendrik Von: Russ Housley <housley@vigilsec.com><mailto:housley@vigilsec.com> Gesendet: Samstag, 9. Oktober 2021 21:07 An: Lijun Liao <lijun.liao@gmail.com><mailto:lijun.liao@gmail.com> Cc: Brockhaus, Hendrik (T RDA CST SEA-DE) <hendrik.brockhaus@siemens.com><mailto:hendrik.brockhaus@siemens.com>; spasm@ietf.org<mailto:spasm@ietf.org>; von Oheimb, David (T RDA CST SEA-DE) <david.von.oheimb@siemens.com><mailto:david.von.oheimb@siemens.com>; John Gray <John.Gray@entrust.com><mailto:John.Gray@entrust.com> Betreff: Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesting a current CRL This is an interesting observation, but it does not seem to cover a certificate with multiple CRL distribution points, indirect CRLs, and delta CRLs. I'm not sure we want all of that complexity here. That said, it does make sense to me to list a distribution point name and the thisUpdate for each one. CRLStatusList ::= SEQUENCE OF CRLStatus CRLStatus ::= SEQUENCE { crldpn DistributionPointName, thisUpdate Time } CRLs ::= SEQUENCE OF CertificateList GenMsg: {id-it TBD}, CRLStatusList GenRep: {id-it TBD}, CRLs | < absent > Russ Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. _______________________________________________ Spasm mailing list Spasm@ietf.org<mailto:Spasm@ietf.org> https://www.ietf.org/mailman/listinfo/spasm<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C8b2adc7606c34e9eba3408d98e63b1fb%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637697381120315091%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Abrx4MMtTywrxP0YCDVvqMTeL9kHwTh2RZf2voIbJrU%3D&reserved=0>
- [lamps] [CMP Updates] Requesting a current CRL Brockhaus, Hendrik
- Re: [lamps] [CMP Updates] Requesting a current CRL Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… John Gray
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Lijun Liao
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… David von Oheimb
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Lijun Liao
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… David von Oheimb
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… David von Oheimb
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… John Gray
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Russ Housley
- Re: [lamps] [EXTERNAL] Re: [CMP Updates] Requesti… Brockhaus, Hendrik