Re: [Sidrops] Signed Object signed with Ed25519 (RFC 8419 proof-of-concept)

Job Snijders <> Mon, 04 September 2023 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B8FFC13AE45 for <>; Mon, 4 Sep 2023 09:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 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_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id djQipTubte9Q for <>; Mon, 4 Sep 2023 09:14:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (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 (Postfix) with ESMTPS id B3DA7C137389 for <>; Mon, 4 Sep 2023 09:14:09 -0700 (PDT)
Received: by with SMTP id 2adb3069b0e04-5008d16cc36so2700483e87.2 for <>; Mon, 04 Sep 2023 09:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; t=1693844048; x=1694448848;; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=5eg7o/HqTKUUglo/gFoBz0JFqkNqkdYkYlWUODQMhTw=; b=GInavb0xQ27nLyRKQexShlF9klKXqQ5SDQED5IQqbomyVmdQuhXT7kvipR1NGMdzLs M4Lo6ZL+Li3gt+qM1LGFBd8Enxw/Dcwmj/0ZCJ9I/qrIAXkpKJLvJxUDXhJLIlz5tfz6 X01Xa5LNRFTARQ/yz4NdDzdFOZ97kuBOpLDHU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1693844048; x=1694448848; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5eg7o/HqTKUUglo/gFoBz0JFqkNqkdYkYlWUODQMhTw=; b=P36jvfKPfCg6NB789nFTkObvZFl91FeXrzWh92XVXAXbkrFwQcELbRsEyNtzlUVU7g lfP8dKZlxKbI4e9VxI+O00mqUPJR5d/A23FQFtZGiqranbZ9HTeSGCLUTrjKF0laswEb Bt87zVDSqoJNJUgAOsfg47t5vXrMNdG4m9P/VMFvDAArbvQKjiDsrFr7nJq6uGja2xTa JpVQFexSnKJnJiAEufxUU8lih+ipe9cVYFPAIdOzR62R87wBs0k0/WMjYMq5ApIwLKZt Ol5MFbRRoh5wy/pINid+mdOObRpwyip+WMEoW6BrV/SyLkdEH359iFDuUUST49S/EbXT MJ8A==
X-Gm-Message-State: AOJu0Yy5cJdZMy0xVmrMND+EFz/1DV1GaLDpxT8rmjAb0mgfS9uqVQ3K H6Oqtb6m68FDYAytJfzKl0lDBg==
X-Google-Smtp-Source: AGHT+IF5RXxc7Ck6Rg5Fu4aD/O7C2Myzo01LfIxTV1d4S66qD9pjjwB5iHf399VDIaU/hAA7tHE02w==
X-Received: by 2002:a05:6512:39ca:b0:4fb:89cd:9616 with SMTP id k10-20020a05651239ca00b004fb89cd9616mr7786676lfu.0.1693844047718; Mon, 04 Sep 2023 09:14:07 -0700 (PDT)
Received: from snel ([2a10:3781:276:3:16f6:d8ff:fe47:2eb7]) by with ESMTPSA id n13-20020a05640206cd00b0052a1a623267sm5996108edy.62.2023. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Sep 2023 09:14:07 -0700 (PDT)
Date: Mon, 04 Sep 2023 18:14:05 +0200
From: Job Snijders <>
To: Russ Housley <>
Message-ID: <ZPYCTXx5NUZB2hI4@snel>
References: <ZPS/VK+6Q8a4dHgA@snel> <> <ZPW+682GaAFXymLo@snel> <>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="P6Xq9fqJUyS+Novt"
Content-Disposition: inline
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <>
Subject: Re: [Sidrops] Signed Object signed with Ed25519 (RFC 8419 proof-of-concept)
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Sep 2023 16:14:13 -0000

On Mon, Sep 04, 2023 at 09:26:37AM -0400, Russ Housley wrote:
> Job wrote:
> >
> > Which RFC specifies the parameters to use with ECDSA in CMS?
> I think you are looking for RFC 5753.


Am I correct to interpret RFC 5753 to mean that secp256r1 (aka X9.62
prime256v1, aka NIST P-256) is recommended over secp256k1 for use in CMS?
I see no mention of secp256k1 in RFC 5753.

For comparison I generated a secp256r1 variant of the same ASPA object,
it clocks in as the second smallest:

RSA EE w/ RSA CA:              1701 bytes [1]
secp256k1 w/ sha256 w/ RSA CA: 1463 bytes [3]
secp256r1 w/ sha256 w/ RSA CA: 1284 bytes (attached)
Ed25519 w/ sha512 w/ RSA CA:   1281 bytes [2]

The 179 byte difference between secp256k1 and secp256r1 is caused by the
secp256k1 public key being encoded differently. The secp256k1 public key
is encoded in 'explicit form', this means that in addition to the 64
byte public key, also a large prime, A & B fields, an uncompressed
Generator field, and an Order field are encoded.

Kind regards,