Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02
Carl Wallace <carl@redhoundsoftware.com> Thu, 12 January 2023 11:45 UTC
Return-Path: <carl@redhoundsoftware.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 443E4C19E0E4 for <spasm@ietfa.amsl.com>; Thu, 12 Jan 2023 03:45:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level:
X-Spam-Status: No, score=-1.995 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhoundsoftware.com
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 PXv2yUHLbksr for <spasm@ietfa.amsl.com>; Thu, 12 Jan 2023 03:45:47 -0800 (PST)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 E8EF9C15153E for <spasm@ietf.org>; Thu, 12 Jan 2023 03:45:47 -0800 (PST)
Received: by mail-qv1-xf2d.google.com with SMTP id i12so12577778qvs.2 for <spasm@ietf.org>; Thu, 12 Jan 2023 03:45:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware.com; s=google; h=mime-version:in-reply-to:references:thread-topic:message-id:to:from :subject:date:user-agent:from:to:cc:subject:date:message-id:reply-to; bh=/Y4lVAVizBREOH9uAiHkdnZpz6rIxv9RewuzI+UEpT0=; b=y7Mgf7vXyBvktPUn2yG3XV+Gijy16TUcq0pvZm2eHODO1CCVK4dBv2ifIAweL+nys+ XFn3GJHpR+PLJny9bLVNXrIJ4PIl731jIJK1xwGL/86guVTmF5EyNjZPZ+OFsZuQcCZY F1kEsZV5Vf4t01CqBLOu3H1bkRjPTcsNvURcE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:in-reply-to:references:thread-topic:message-id:to:from :subject:date:user-agent:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/Y4lVAVizBREOH9uAiHkdnZpz6rIxv9RewuzI+UEpT0=; b=sgSteBktNLujPTmxDuxDsb7h04zN6+XH+2Of+koaDKZhJHAvZ7x9hsRuGoj7RYoI9K rVgf1Jnw2ucIMbE+6cDoPbypOWy+1xH5iZENlabTbN65CMeEMJDlscMCv+VchBqA0ES0 ZtD9594+wzCfb2O0YAINA6VeWFDYlDqMg86VweXMEuuQYlC/pDex0NhpBqPW9uMKapRI kyUS9iDJHxS71KgVlByc/KBl4rd9nYHQ8fxwfY1r47Vxg5t3ufGromnfWXTXKH+H06at AQkHIzGYWGB9YzKotSv1X/0zwxPqGeeAni8riCpEp9rCFohwJYzYQmuELNTNouNqWsv4 gZcw==
X-Gm-Message-State: AFqh2kqtYdF5Sx5ChwfKM5r4ji7hIP1nthLhX2y/yquzRza6az2MNCDm IUcIzVuieAkhEaFmoMnzFW0+xg==
X-Google-Smtp-Source: AMrXdXtzW3+LCr0SZSKPaCheAxCIWT5p3Q+Hw6zRhej8jNyklvk6vJEq/whpdzDCytwLRt5iX4D9qw==
X-Received: by 2002:a05:6214:350d:b0:533:bcd4:3509 with SMTP id nk13-20020a056214350d00b00533bcd43509mr13617406qvb.7.1673523945691; Thu, 12 Jan 2023 03:45:45 -0800 (PST)
Received: from [192.168.2.16] (pool-74-96-253-253.washdc.fios.verizon.net. [74.96.253.253]) by smtp.gmail.com with ESMTPSA id q6-20020a05620a0d8600b006fa43e139b5sm10634075qkl.59.2023.01.12.03.45.44 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2023 03:45:45 -0800 (PST)
User-Agent: Microsoft-MacOutlook/16.69.23010700
Date: Thu, 12 Jan 2023 06:45:44 -0500
From: Carl Wallace <carl@redhoundsoftware.com>
To: Mike Ounsworth <Mike.Ounsworth@entrust.com>, "Kampanakis, Panos" <kpanos@amazon.com>, "aebecke@uwe.nsa.gov" <aebecke@uwe.nsa.gov>, LAMPS <spasm@ietf.org>
Message-ID: <58AA8EB8-89E3-4506-9C5F-56BD5EFDCA5F@redhoundsoftware.com>
Thread-Topic: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02
References: <PH0PR00MB10003EC6A096FE0A363BBFB9F5459@PH0PR00MB1000.namprd00.prod.outlook.com> <PH0PR00MB10002A7A2850A1333B4F6C00F54A9@PH0PR00MB1000.namprd00.prod.outlook.com> <35BEB1D9-7EA5-4CD4-BADA-88CCB0E9E8F9@vigilsec.com> <6FB4E76C-0AFD-4D00-B0FC-63F244510530@vigilsec.com> <bd5a491c78c8406b8de6414aff4f5223@amazon.com> <SA0PR09MB72412D6BBBC556716B5FBDEDF1FF9@SA0PR09MB7241.namprd09.prod.outlook.com> <adfdcfcfb0f84c63b83bc60cb9a48cfa@amazon.com> <CH0PR11MB573917AD78637794B2A424249FFC9@CH0PR11MB5739.namprd11.prod.outlook.com> <ca14b6a4dc624d5a8721a76fba0e0b2f@amazon.com> <CH0PR11MB5739F7AB185E366BFEB9F1A69FFC9@CH0PR11MB5739.namprd11.prod.outlook.com> <774557DE-522F-4A3C-B360-6B7C9103F579@redhoundsoftware.com> <CH0PR11MB5739D1D766DDFC5B48D59E159FFC9@CH0PR11MB5739.namprd11.prod.outlook.com>
In-Reply-To: <CH0PR11MB5739D1D766DDFC5B48D59E159FFC9@CH0PR11MB5739.namprd11.prod.outlook.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3756350744_591646538"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/XASsyBjIKn3kpLHTQLKqzZJ6wH8>
Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02
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: Thu, 12 Jan 2023 11:45:52 -0000
Inline… From: Mike Ounsworth <Mike.Ounsworth@entrust.com> Date: Wednesday, January 11, 2023 at 11:17 AM To: Carl Wallace <carl@redhoundsoftware.com>, "Kampanakis, Panos" <kpanos@amazon.com>, "aebecke@uwe.nsa.gov" <aebecke@uwe.nsa.gov>, LAMPS <spasm@ietf.org> Subject: RE: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 Sorry, I should be more precise: By “mix & match” I mean that in the hybrid mode you present two certificates, one from each device when the relying party is really expecting you to present two certs from the same device. Yes you *could* structure your DNs or SANs to be unique per device, but this draft provides a binding mech that does not require any specific PKI naming conventions. [CW] The draft does not address “from the same device” or “from each device”. It’s just a means of binding an existing key to a new key. Under the assumption that this draft is providing a meaningful way to solve this problem, then I support its adoption. If we believe that the mechanism in this draft is not doing that, ie that there are no PKI deployments in which this draft is actually providing stronger bindings than we already have with Subject / SAN names, then I may reconsider my support for adoption. [CW] I don’t think anyone has suggested that signing a new public key with an existing private key is not a stronger binding than binding with names (albeit at present the draft has the existing key sign requestTime || issuerNameAndSerial, not the new key). Given name-based binding is already possible, the question is whether adding a means to bind two keys cryptographically is worthwhile. Composite achieves cryptographic binding by placing > 1 key in same certificate, this provides an alternative for non-composite. That seems worth adopting. --- Mike Ounsworth From: Carl Wallace <carl@redhoundsoftware.com> Sent: Wednesday, January 11, 2023 9:45 AM To: Mike Ounsworth <Mike.Ounsworth@entrust.com>; Kampanakis, Panos <kpanos@amazon.com>; aebecke@uwe.nsa.gov; LAMPS <spasm@ietf.org> Subject: [EXTERNAL] Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Inline… From: Spasm <spasm-bounces@ietf.org> on behalf of Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> Date: Wednesday, January 11, 2023 at 10:12 AM To: "Kampanakis, Panos" <kpanos=40amazon.com@dmarc.ietf.org>, "aebecke@uwe.nsa.gov" <aebecke@uwe.nsa.gov>, LAMPS <spasm@ietf.org> Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 Again, I’m guessing at the intended use-case here. Let’s say I am in possession of two PIV ID cards. They both belong to me, ergo will have the same Subject and SANs. [CW] It is not necessarily the case that your two PIV cards would have the same subject DN or SAN. It’s common for people to be issued smart cards for different functions or even within different government agencies (or perhaps to have a personal card and a group/role card) such that one or both of subject DN and SAN differ. But they are not the same device. If both PIV cards are hybrids, then there are 4 certs in play, all of which will have the same Subject and SANs, but you should not mix&match them. This draft provides a mechanism to tag which pairs of certs “belong together” even though they all belong to the same PKI logical entity. [CW] I’m not certain what you mean by “mix and match” or why that ought not be done, but it sounds like you are suggesting the proposed new extension be used to bind one cert on a smart card to the other (presumably even if the holder only possesses one smart card). Why would that be needed? A common case is derived credentials, which typically do have same DN and SAN. Those are intended to be “mixed and matched”, i.e., I would expect to be able to access the same resources using my phone or tablet as I can with my PIV card (even if one featured RSA keys and the other EC keys). [CW] The extension really can’t mean much more than that an entity is demonstrating control of the private key corresponding to the related cert identified in an attribute included in a CSR. The utility of this proof would be up to the relying party. Any proof of same identity or same hardware device would be achieved through something other than this extension (as currently described, anyway). If one were to require DNs to match (to avoid cross-organizational recognition), then Panos’ point seems right, i.e., why not just check the names. --- Mike Ounsworth From: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org> Sent: Wednesday, January 11, 2023 8:49 AM To: Mike Ounsworth <Mike.Ounsworth@entrust.com>; aebecke@uwe.nsa.gov; LAMPS <spasm@ietf.org> Subject: [EXTERNAL] RE: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. If the related certs have the same DN (I was calling it same Subject or SAN in my email) then the verifier can rest assured the two certs belong to the same entity without the need of a new extension. That is what I was originally pointing out. Now, if there is no identity overlap as Allie suggested then I was saying that I am not sure what the verifier is supposed to do when it is presented with these two related certs with completely different identities. From: Spasm <spasm-bounces@ietf.org> On Behalf Of Mike Ounsworth Sent: Wednesday, January 11, 2023 8:33 AM To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>; aebecke@uwe.nsa.gov <aebecke=40uwe.nsa.gov@dmarc.ietf.org>; LAMPS <spasm@ietf.org> Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Panos, I assume in their use-case, endpoints will treat matching SANs as necessary but not sufficient. Making up an example here, if you’re receiving a TLS client-auth connection from DN: cn=Alice,dc=example,dc=com then both certs had better have the same DN (otherwise it’s totally unclear which user is trying to log in) *PLUS* one of them had better have a RelatedCertificate extn that lines up with the other cert to prove that both private keys are contained on the same hardware device (or wtv the semantics of that extension mean in their environment). --- Mike Ounsworth From: Spasm <spasm-bounces@ietf.org> On Behalf Of Kampanakis, Panos Sent: Tuesday, January 10, 2023 8:43 PM To: aebecke@uwe.nsa.gov <aebecke=40uwe.nsa.gov@dmarc.ietf.org>; LAMPS <spasm@ietf.org> Subject: [EXTERNAL] Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 WARNING: This email originated outside of Entrust. DO NOT CLICK links or attachments unless you trust the sender and know the content is safe. Hi Allie, Thx. If there is no overlap between the Subject Name or SANs in the two related certs, should they be used at the same time in a PQ transition scenario since the verifier can only be talking to one identity at a time? To rephrase that, if the two related certs include completely different identities, wouldn’t that be a problem for the TLS, IKEv2, etc verifier? - When the verifier is presented with a classical RSA peer cert, it confirms the identity of the cert is the identity it is talking to. - When the verifier is presented with just one PQ peer related-cert, it will confirm the identity of the cert is the identity it is talking to. - While still in the PQ transition phase, when the verifier is presented with one classical RSA peer cert and one PQ peer related-cert, what is it supposed to do if the identities in these certs are completely different? Verify only one identity and assume the other one belongs to the same peer because of POP at issuance? From: Spasm <spasm-bounces@ietf.org> On Behalf Of aebecke@uwe.nsa.gov Sent: Tuesday, January 10, 2023 12:38 PM To: Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org>; Russ Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org> Subject: RE: [EXTERNAL][lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Panos, Thanks for the comments. It is not always the case that SANs will unambiguously identify a certificate, as they are not globally unique. Especially in the case that may arise in which a different CA has issued a related certificate, we want to provide strong assurance that the certificate is under the control of the correct end-entity. Matching names depends on mapping the namespaces of the issuers (which may suffice for discovery); our draft provides the existing (traditional) PoP nested in the new (PQC) PoP, which we think provides more assurance. Cheers, Alie ---- From: Spasm <spasm-bounces@ietf.org> on behalf of Kampanakis, Panos <kpanos=40amazon.com@dmarc.ietf.org> Sent: Thursday, January 5, 2023 9:33 PM To: Russ Housley <housley@vigilsec.com>; LAMPS <spasm@ietf.org> Subject: Re: [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 My previous objections and concerns have not been addressed, but maybe I had misunderstood the spirit of the draft. So let me repeat the last, most important, question after Mike's presentation of the draft in IETF-115. It seems that the draft just wants to provide an extension that says cert A and cert B are related and owned by the same entity and allow a CSR to prove that the requester of Cert B also owns the private key for Cert A. In other words the flow would work as: - Entity X generates a CSR for CertA and proves it owns the private key for A. The issuer generates CertA after verifying the ownership of private key A and the identity of X. - Entity X generates a CSR for CertB which is related to CertA and proves it owns the private key for A and B. The issuer generates CertB (related-to-CertA) after verifying the ownership of private keys A and B and the identity of X. - Entity X owns CertA and CertB which it uses to be authenticated in protocol Y. The protocol Y verifier gets CertA and CertB, it verifies the peer owns the private key for CertA, CertB and it confirms it trusts these certs were issued for Entity X. Now let's forget the draft and say we do not use a new X.509 or CSR extension. And let's say the flow now works as - Entity X generates a CSR for CertA and proves it owns the private key for A. The issuer generates CertA after verifying the ownership of private key A and the identity of X. - Entity X generates a CSR for CertB and proves it owns the private key for B. The issuer generates CertB after verifying the ownership of private key B and the identity of X. - Entity X owns CertA and CertB which it uses to be authenticated in protocol Y. The protocol Y verifier gets CertA and CertB, it verifies the peer owns the private key for CertA, CertB and it confirms it trusts BOTH of these certs were issued for the same entity Entity X. Why is the former flow better over the latter? In other words, if CertA and CertB were issued separately, why could the verifier not just use the Subject Name or SANs to confirm the certs relationship while verifying? -----Original Message----- From: Spasm <spasm-bounces@ietf.org> On Behalf Of Russ Housley Sent: Thursday, January 5, 2023 6:02 PM To: LAMPS <spasm@ietf.org> Subject: [EXTERNAL] [lamps] Call for adoption of draft-becker-guthrie-cert-binding-for-multi-auth-02 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Do the changes that were made in -02 of the Internet-Draft resolve the concerns that were previously raised? On behalf of the LAMPS WG Chairs, Russ > On Sep 15, 2022, at 11:44 AM, Russ Housley <housley@vigilsec.com> wrote: > > There has been some discussion of https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-becker-guthrie-cert-binding-for-multi-auth%2F&data=05%7C01%7Caebecke%40uwe.nsa.gov%7Cd4dd908b5872439f1f0408daef96c7fd%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638085728259980926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=nVzReEXbWrb8sHQPdGWv9G95WoP1GiKdjlHZP6DesmA%3D&reserved=0. During the discussion at IETF 114, we agree to have a call for adoption of this document. > > Should the LAMPS WG adopt “Related Certificates for Use in Multiple Authentications within a Protocol” indraft-becker-guthrie-cert-binding-for-multi-auth-01? > > Please reply to this message by Friday, 30 September 2022 to voice your support or opposition to adoption. > > On behalf of the LAMPS WG Chairs, > Russ > _______________________________________________ Spasm mailing list Spasm@ietf.org https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Caebecke%40uwe.nsa.gov%7Cd4dd908b5872439f1f0408daef96c7fd%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638085728259980926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=qkCBqRILB587BacZgK9AHy6kqqQmfrTGeqv9dqm1RXg%3D&reserved=0 _______________________________________________ Spasm mailing list Spasm@ietf.org https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspasm&data=05%7C01%7Caebecke%40uwe.nsa.gov%7Cd4dd908b5872439f1f0408daef96c7fd%7Cd61e9a6ffc164f848a3e6eeff33e136b%7C0%7C0%7C638085728259980926%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=qkCBqRILB587BacZgK9AHy6kqqQmfrTGeqv9dqm1RXg%3D&reserved=0 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 https://www.ietf.org/mailman/listinfo/spasm
- [lamps] Call for adoption of draft-becker-guthrie… Russ Housley
- Re: [lamps] [EXTERNAL] Call for adoption of draft… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Call for adoption of draft… Russ Housley
- Re: [lamps] Call for adoption of draft-becker-gut… Corey Bonnell
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Michael Jenkins
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Russ Housley
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… John Gray
- Re: [lamps] Call for adoption of draft-becker-gut… Russ Housley
- Re: [lamps] Call for adoption of draft-becker-gut… Russ Housley
- Re: [lamps] Call for adoption of draft-becker-gut… Tomas Gustavsson
- Re: [lamps] Call for adoption of draft-becker-gut… Stephen Farrell
- Re: [lamps] [EXTERNAL] Re: Call for adoption of d… Mike Ounsworth
- Re: [lamps] [EXTERNAL] Re: Call for adoption of d… Rebecca Guthrie
- Re: [lamps] Call for adoption of draft-becker-gut… Russ Housley
- Re: [lamps] Call for adoption of draft-becker-gut… Stephen Farrell
- Re: [lamps] [EXTERNAL] Re: Call for adoption of d… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Michael Jenkins
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Blumenthal, Uri - 0553 - MITLL
- Re: [lamps] Call for adoption of draft-becker-gut… Stephen Farrell
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Tomas Gustavsson
- Re: [lamps] Call for adoption of draft-becker-gut… Russ Housley
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Tomas Gustavsson
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Tomas Gustavsson
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- [lamps] Call for adoption of draft-becker-guthrie… Russ Housley
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… aebecke@uwe.nsa.gov
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Carl Wallace
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Tomofumi Okubo
- Re: [lamps] Call for adoption of draft-becker-gut… Santosh Chokhani
- Re: [lamps] Call for adoption of draft-becker-gut… Carl Wallace
- Re: [lamps] Call for adoption of draft-becker-gut… Carl Wallace
- Re: [lamps] Call for adoption of draft-becker-gut… Tadahiko Ito
- Re: [lamps] Call for adoption of draft-becker-gut… Julien Prat
- Re: [lamps] Call for adoption of draft-becker-gut… Tim Hollebeek
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Michael Richardson
- Re: [lamps] Call for adoption of draft-becker-gut… aebecke@uwe.nsa.gov
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Santosh Chokhani
- Re: [lamps] Call for adoption of draft-becker-gut… Michael Markowitz
- Re: [lamps] Call for adoption of draft-becker-gut… Mike Ounsworth
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Tomofumi Okubo
- Re: [lamps] Call for adoption of draft-becker-gut… Tim Hollebeek
- Re: [lamps] Call for adoption of draft-becker-gut… Kampanakis, Panos
- Re: [lamps] Call for adoption of draft-becker-gut… Seo Suchan
- Re: [lamps] Call for adoption of draft-becker-gut… Santosh Chokhani
- Re: [lamps] Call for adoption of draft-becker-gut… Tomofumi Okubo
- Re: [lamps] Call for adoption of draft-becker-gut… Santosh Chokhani
- Re: [lamps] Call for adoption of draft-becker-gut… Tomofumi Okubo
- Re: [lamps] Call for adoption of draft-becker-gut… Russ Housley