Re: [lamps] draft-housley-lamps-norevavail-00
Russ Housley <housley@vigilsec.com> Fri, 19 May 2023 18:23 UTC
Return-Path: <housley@vigilsec.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 ED0A0C14CF05 for <spasm@ietfa.amsl.com>; Fri, 19 May 2023 11:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.799
X-Spam-Level:
X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, TRACKER_ID=0.1] autolearn=no autolearn_force=no
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 Q2H1K2crXjvE for <spasm@ietfa.amsl.com>; Fri, 19 May 2023 11:23:20 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 6BC75C14F736 for <spasm@ietf.org>; Fri, 19 May 2023 11:23:20 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 2C2FEF03FD; Fri, 19 May 2023 14:23:19 -0400 (EDT)
Received: from [192.168.1.161] (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 0CD51F0423; Fri, 19 May 2023 14:23:19 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <1D0A1FF3-6E6E-4EB2-8E3D-59C93C2B5C9F@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_706B9066-EC75-4B96-A0D8-526B016B68A7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
Date: Fri, 19 May 2023 14:23:18 -0400
In-Reply-To: <SN7PR14MB6492BA2FF0D14C8CE1891406837C9@SN7PR14MB6492.namprd14.prod.outlook.com>
Cc: LAMPS <spasm@ietf.org>, Joe Mandel <Joe.Mandel@secureg.io>, Tomofumi Okubo <tomofumi.okubo@gmail.com>
To: Tim Hollebeek <tim.hollebeek@digicert.com>
References: <168444309553.24047.14923062710269229403@ietfa.amsl.com> <E2BE1DCD-A241-4DDF-A5EC-DD3209C4CDA2@vigilsec.com> <SN7PR14MB649255412EFADEE00E0F6B00837C9@SN7PR14MB6492.namprd14.prod.outlook.com> <CH0PR11MB5739CCB7CDDCAD1D11F04DAE9F7C9@CH0PR11MB5739.namprd11.prod.outlook.com> <BB5FA3FE-445A-44C4-B4C7-471B15310582@akamai.com> <CH0PR11MB5739E4C8D14294F6868D18929F7C9@CH0PR11MB5739.namprd11.prod.outlook.com> <SN7PR14MB6492BA2FF0D14C8CE1891406837C9@SN7PR14MB6492.namprd14.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.21)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/XFNptR9EsNRZh-SVOzVm-O967yI>
Subject: Re: [lamps] draft-housley-lamps-norevavail-00
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 19 May 2023 18:23:25 -0000
Tim: The explicit flag is _very_ short. When I made a bogus certificate to see how short, I was surprise to lear that OpenSSL already knows the OID... Below is the whole certificate and the OpenSSL text output if you want to use some other tool to take a look. Also, the explicit flag would allow the client to skip the OCSP query, even if it is going to fail soft. Russ = = = = = = = $openssl x509 -inform pem -in example_server_ecdsa.pem -text Certificate: Data: Version: 3 (0x2) Serial Number: a5:b3:54:28:1b:b0:6e:51 Signature Algorithm: ecdsa-with-SHA384 Issuer: C = US, ST = VA, L = Herndon, O = Bogus CA Validity Not Before: May 19 17:57:30 2023 GMT Not After : May 26 17:57:30 2023 GMT Subject: CN = www.example.com, O = Example Corp., C = US Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:57:25:5a:14:09:8d:8e:55:46:13:cb:dc:c2:74: aa:6b:ab:7a:e0:22:df:1b:88:9a:61:ac:dd:f5:d6: 6b:50:fc:83:d7:fe:cf:f4:27:11:fb:cf:35:8e:4a: d1:30:ca:e0:2a:26:61:d2:ff:f1:91:dc:1d:b7:83: 61:23:82:fa:23:8b:c4:5a:a0:e6:3b:42:00:73:e1: 53:e7:2c:ae:ac:15:8c:90:85:22:95:d4:6f:0e:b3: e8:0a:88:1a:7c:e2:6c ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 No Revocation Available: .. X509v3 Subject Alternative Name: URI:http://www.example.com/ X509v3 Key Usage: Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication Netscape Comment: This certificate cannot be trusted for any purpose. X509v3 Subject Key Identifier: 84:3A:04:AC:34:73:61:19:39:9A:B6:45:6A:D3:7C:68:D3:5F:3D:DC X509v3 Authority Key Identifier: F2:35:DB:34:04:DA:A5:55:F2:BD:69:03:99:B0:62:EC:E2:15:08:C1 Signature Algorithm: ecdsa-with-SHA384 Signature Value: 30:65:02:31:00:d2:cf:b9:75:36:9b:4c:7a:bf:ef:ae:3a:6f: 86:91:97:34:13:47:e4:2f:7d:b2:15:4e:bc:a6:25:91:f9:fb: 04:2b:d8:9a:f1:86:e9:56:91:ef:18:93:e2:e8:5b:77:51:02: 30:44:57:7c:d4:eb:57:44:c3:b8:1e:11:1d:87:ec:27:6b:0b: 86:c7:34:4c:f5:0d:7e:08:52:59:e7:1a:9d:df:c2:38:2e:12: 0d:58:9d:fd:7c:a0:ec:0d:43:42:bc:d3:be -----BEGIN CERTIFICATE----- MIICizCCAhGgAwIBAgIJAKWzVCgbsG5RMAoGCCqGSM49BAMDMD8xCzAJBgNVBAYT AlVTMQswCQYDVQQIDAJWQTEQMA4GA1UEBwwHSGVybmRvbjERMA8GA1UECgwIQm9n dXMgQ0EwHhcNMjMwNTE5MTc1NzMwWhcNMjMwNTI2MTc1NzMwWjA/MRgwFgYDVQQD Ew93d3cuZXhhbXBsZS5jb20xFjAUBgNVBAoTDUV4YW1wbGUgQ29ycC4xCzAJBgNV BAYTAlVTMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEVyVaFAmNjlVGE8vcwnSqa6t6 4CLfG4iaYazd9dZrUPyD1/7P9CcR+881jkrRMMrgKiZh0v/xkdwdt4NhI4L6I4vE WqDmO0IAc+FT5yyurBWMkIUildRvDrPoCogafOJso4HYMIHVMAkGA1UdOAQCBQAw IgYDVR0RBBswGYYXaHR0cDovL3d3dy5leGFtcGxlLmNvbS8wCwYDVR0PBAQDAgeA MBMGA1UdJQQMMAoGCCsGAQUFBwMBMEIGCWCGSAGG+EIBDQQ1FjNUaGlzIGNlcnRp ZmljYXRlIGNhbm5vdCBiZSB0cnVzdGVkIGZvciBhbnkgcHVycG9zZS4wHQYDVR0O BBYEFIQ6BKw0c2EZOZq2RWrTfGjTXz3cMB8GA1UdIwQYMBaAFPI12zQE2qVV8r1p A5mwYuziFQjBMAoGCCqGSM49BAMDA2gAMGUCMQDSz7l1NptMer/vrjpvhpGXNBNH 5C99shVOvKYlkfn7BCvYmvGG6VaR7xiT4uhbd1ECMERXfNTrV0TDuB4RHYfsJ2sL hsc0TPUNfghSWecand/COC4SDVid/Xyg7A1DQrzTvg== -----END CERTIFICATE----- $ > On May 19, 2023, at 1:23 PM, Tim Hollebeek <tim.hollebeek@digicert.com> wrote: > > I was aware of that argument, but I was wondering if there was anything additional going on here that I had failed to think of. With some people being very focused on certificate size, having an extension B that says “extension A intentionally left blank” perhaps needs some justification. Or perhaps not. On balance, I think it is best people have the option to be able to do so, for the reasons Rich mentions, but I have no strong feelings about it. > > Since Mike mentioned browsers, when this last came up at CABF about seven years ago, we also answered the question about how browsers would handle this. It’s actually trivial since they all mostly soft-fail on OCSP anyway. In fact, in response to those discussions, Mozilla added code to ignore OCSP extensions for certificates with lifetimes less than some small number of days. Some people even use it. > > -Tim > > From: Mike Ounsworth <Mike.Ounsworth@entrust.com <mailto:Mike.Ounsworth@entrust.com>> > Sent: Friday, May 19, 2023 12:48 PM > To: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org <mailto:rsalz=40akamai.com@dmarc.ietf.org>>; Tim Hollebeek <tim.hollebeek@digicert.com <mailto:tim.hollebeek@digicert.com>>; Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>; LAMPS <spasm@ietf.org <mailto:spasm@ietf.org>> > Cc: Joe Mandel <Joe.Mandel@secureg.io <mailto:Joe.Mandel@secureg.io>>; Tomofumi Okubo <tomofumi.okubo@gmail.com <mailto:tomofumi.okubo@gmail.com>> > Subject: RE: [lamps] draft-housley-lamps-norevavail-00 > > > In my security experience, it is always better to explicitly state something – the alarm did not sound – rather than have something implied by its absence > > Fair enough. > > --- > Mike Ounsworth > > From: Salz, Rich <rsalz=40akamai.com@dmarc.ietf.org <mailto:rsalz=40akamai.com@dmarc.ietf.org>> > Sent: Friday, May 19, 2023 10:44 AM > To: Mike Ounsworth <Mike.Ounsworth@entrust.com <mailto:Mike.Ounsworth@entrust.com>>; Tim Hollebeek <tim.hollebeek@digicert.com <mailto:tim.hollebeek@digicert.com>>; Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>>; LAMPS <spasm@ietf.org <mailto:spasm@ietf.org>> > Cc: Joe Mandel <Joe.Mandel@secureg.io <mailto:Joe.Mandel@secureg.io>>; Tomofumi Okubo <tomofumi.okubo@gmail.com <mailto:tomofumi.okubo@gmail.com>> > Subject: [EXTERNAL] Re: [lamps] draft-housley-lamps-norevavail-00 > > WARNING: This email originated outside of Entrust. > DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. > So yeah, exactly what Tim said: in what case is it helpful to explicitly state “No revocation info available” vs just leaving those extns out? > > (Separate thread, separate issue) > > In my security experience, it is always better to explicitly state something – the alarm did not sound – rather than have something implied by its absence – did the alarm sound? Do I know the CA is modern, did it make a mistake (been known to happen), etc. > > > 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.
- [lamps] draft-housley-lamps-norevavail-00 Russ Housley
- Re: [lamps] draft-housley-lamps-norevavail-00 Tomofumi Okubo
- Re: [lamps] draft-housley-lamps-norevavail-00 Tim Hollebeek
- Re: [lamps] draft-housley-lamps-norevavail-00 Mike Ounsworth
- Re: [lamps] draft-housley-lamps-norevavail-00 Salz, Rich
- Re: [lamps] draft-housley-lamps-norevavail-00 Salz, Rich
- Re: [lamps] draft-housley-lamps-norevavail-00 Russ Housley
- Re: [lamps] draft-housley-lamps-norevavail-00 Russ Housley
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] draft-housley-lamps-norevavail-00 Mike Ounsworth
- Re: [lamps] draft-housley-lamps-norevavail-00 Tim Hollebeek
- Re: [lamps] draft-housley-lamps-norevavail-00 Tim Hollebeek
- Re: [lamps] draft-housley-lamps-norevavail-00 Russ Housley
- Re: [lamps] draft-housley-lamps-norevavail-00 Seo Suchan
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Russ Housley
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Deb Cooley
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] draft-housley-lamps-norevavail-00 Jeffrey Walton
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Watson Ladd
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Tim Hollebeek
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Tim Hollebeek
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Russ Housley
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Russ Housley
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Salz, Rich
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: draft-housley-lamps-no… Michael StJohns