From nobody Mon Jan 30 10:57:40 2023
Return-Path: <tjtncks@gmail.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 3509FC14CEFC
 for <spasm@ietfa.amsl.com>; Mon, 30 Jan 2023 10:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.597
X-Spam-Level: 
X-Spam-Status: No, score=-0.597 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, FREEMAIL_FROM=0.001,
 FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999,
 NICE_REPLY_A=-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=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
 header.d=gmail.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 9il-Sd03LEqT for <spasm@ietfa.amsl.com>;
 Mon, 30 Jan 2023 10:57:38 -0800 (PST)
Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com
 [IPv6:2607:f8b0:4864:20::1029])
 (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 B0469C14EAA3
 for <spasm@ietf.org>; Mon, 30 Jan 2023 10:57:38 -0800 (PST)
Received: by mail-pj1-x1029.google.com with SMTP id
 t12-20020a17090aae0c00b00229f4cff534so13876282pjq.1
 for <spasm@ietf.org>; Mon, 30 Jan 2023 10:57:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 
 h=content-transfer-encoding:in-reply-to:subject:from:references:to
 :content-language:user-agent:mime-version:date:message-id:from:to:cc
 :subject:date:message-id:reply-to;
 bh=hFVQnd/6wBdrOFHD81tddo3KzS9/ndob2Il+pklTuqM=;
 b=aBiKaTBj3hBc9vrgsn7iJTdmlXUQE/UAsOa1XAq0Br/wkm3Eu5gXw6w4gWCvQ13//H
 L4CXhQsxvR2PajI9k3btMgaW3qw6P0CKD9EEx4wri6v+n4W0DjiGD3CEv8aINr3/38Jd
 MDmjwg3QdSfD1+NDhp9ViON5oZ3waa3PTvxgJeCkx1s18bQwkygvUeqg5ATUbhrlBqf5
 zPXFgA2qEY6ZTI2Pobmv2yneG6SKs/IM4PKqRJqqynLJP6HhR5+cabayPARcakeU5Hsg
 BBn7LQWtTluxb+wqe8qXVenw24X8qOrWr0ZZFUl2h2aZi/rIxxdPH58qzE2kBFx0u/2v
 +UHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=content-transfer-encoding:in-reply-to:subject:from:references:to
 :content-language:user-agent:mime-version:date:message-id
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=hFVQnd/6wBdrOFHD81tddo3KzS9/ndob2Il+pklTuqM=;
 b=QiGm4xzt/CkX8aODptHmOjZbyIvPhtr8637E6l65jcoEckKu0W+aZ7GX4ArRj2/yJV
 CgDxC11QjUsCI+ESl01zXmj/vK5CSIjDg/MI457To0lVYO7jbokQ4saMd8NJuK3GcQMp
 rTUaxu36lfv7H4PJMCL9OQmsHO0vdvADxaJDSuAky/ZY5KlboKnmUGw8qaj0/AwER08n
 Tp7M1+iQEH0J1bwYD1pofOlwns/T1bDyEvqTyVCuxILr3opZoFPhB1r4XKuVU673RdId
 31cap84ATN8Cv4Vax+bZcrYMnPzABb6i8YoOkauYmCo0ZFSa13stslIM2CfTETmWEbal
 BDOQ==
X-Gm-Message-State: AO0yUKWbWzUT94jHkkJFQarEQl3PXs6cQzMXZIw7SFHJ80pYMZe1g9Xl
 roRu20+BQQU23dY9aqmtKC2ESFQkuLl4uA==
X-Google-Smtp-Source: AK7set9iUyME5Lsfk44p6JxCAHgg16icBKCz3U4lidvP7HHZfFwwAHZzE0bDaYfcFdnNnFFuraQ/2g==
X-Received: by 2002:a05:6a20:1592:b0:be:9249:236c with SMTP id
 h18-20020a056a20159200b000be9249236cmr3632384pzj.35.1675105057909; 
 Mon, 30 Jan 2023 10:57:37 -0800 (PST)
Received: from [192.168.1.172] ([118.32.103.160])
 by smtp.gmail.com with ESMTPSA id
 d197-20020a6336ce000000b0042988a04bfdsm7199364pga.9.2023.01.30.10.57.36
 for <spasm@ietf.org>
 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
 Mon, 30 Jan 2023 10:57:37 -0800 (PST)
Message-ID: <f04487ba-594d-ae24-828a-e08889c3b51e@gmail.com>
Date: Tue, 31 Jan 2023 03:57:36 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.6.1
Content-Language: en-US
To: spasm@ietf.org
References: <CACsn0c=uPvp_hmakpfPff8WkYh1q9NhjfTJYs7iFu_czL2yAyA@mail.gmail.com>
 <DS7PR12MB5983E36300151BFC47E5CB34AAD39@DS7PR12MB5983.namprd12.prod.outlook.com>
 <CH0PR11MB57392033396F181A9853FAD79FD39@CH0PR11MB5739.namprd11.prod.outlook.com>
 <CACsn0c=n5TLZRywpRCQhpyoxX65OfA9p6e5iz9jKnnEVSX4zmQ@mail.gmail.com>
From: Seo Suchan <tjtncks@gmail.com>
In-Reply-To: <CACsn0c=n5TLZRywpRCQhpyoxX65OfA9p6e5iz9jKnnEVSX4zmQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/iXz-SPCcUVlXGtKvHfeXNEDb2SI>
Subject: Re: [lamps] Hybrid pkix isn't needed
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: Mon, 30 Jan 2023 18:57:39 -0000

Think there are two kinds of fail mode hybrid cert try to guard against: 
Quantum computer came out breaking classical asymmetrical crypto, or PQ 
algorithm we chooses was not that great and it broken down by new 
classical attack

2023-01-31 오전 3:49에 Watson Ladd 이(가) 쓴 글:
> On Mon, Jan 30, 2023 at 10:30 AM Mike Ounsworth
> <Mike.Ounsworth@entrust.com> wrote:
> <snip>
>
>>
>> For TLS or IKEv2, yes, signatures are less urgent than encryption, but in general you know that you’re fighting a losing battle here, right? Especially since the NSA in their CNSA 2.0 have marked code-signing as the most urgent use case to migrate to PQC. The idea is that a device will leave your manufacturing facility with a burned-in trust anchor that it should use for validating future firmware patches. For good reason you can’t change trust anchors in the field, so we need to make sure those algorithms are going to stand the test of time for the lifetime of the device.
> In that case what's the point of hybridization: you need very high
> security due to lack of updates, you're not signing very much, so XMSS
> or another hashed based scheme is the obvious choice. Just issue those
> certs, rather than add complex behavior to find some other cert in the
> chain to actually use. Although I do wonder what happens when the key
> you use leaks.
>
>>
>>
>> Another example is PDF signing; if I can factor the signer’s private key so I can modify and re-sign the PDF then what’s stopping me from also back-dating the timestamps?
>>
>>
>>
>> Yet another is S/MIME email certificates: you need PQ CAs before you can issue PQ encryption certs.
> Why? There's nothing wrong with mixed algorithms in a chain. The
> bigger issue here is root program policies about what can be signed.
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm

