Re: How to select the ASN.1 structure of EC-SDSA (Schnorr signature with ECC)?

On 8/23/2022 6:19 AM, Ernst G Giessmann wrote:
> Am 2022-08-22 um 22:27 schrieb Michael StJohns:
>> On 8/22/2022 3:04 PM, Ernst G Giessmann wrote:
>> AFAICT, not explicitly, but the German version of the spec
>> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03111/BSI-TR-03111_V-2-1_pdf.pdf?__blob=publicationFile&v=1
>> suggests that the r field of a ECSDSA signature is still an integer,
>> converted from the R value using the OS2I primitive on formation, and
>> the I2OS primitive for verification.    That works for both the simple
>> r||s and ASN1 encodings.
>>
>> Mike
> Mike,
> thanks for the reference, but I'm not very sure that this is the right
> approach. In contrast to EC-DSA the r field in EC-SDSA is clearly a
> constant length hash value, and therefore the appropriate encoding seems
> to be the constant length bit or octet string representation. An integer
> encoding must ignore leading zero bits and has to consider the first bit
> as a sign.
>
> Other places where hash values show up in ASN1 are the KeyIdentifier in
> X.509, the KeyHash in OCSP and the digest value encoding in PKCS#1 v1.5.
> All are encoded as octet strings.
>
> /Ernst
>
> OT: In case of EC-FSDSA (full Schnorr) the r field is the elliptic curve
> point P (aka pre-signature). Should it also be encoded as an integer? ;-).
>
>

The point is that there are multiple encodings for a EC signature - e.g. 
ASN1, simple (aka hardware), and I think JSON?  Smart cards too.   In 
the simple (e.g. hardware originated) case for ECSDSA, you would use the 
I2OS primitive to express the s value as a 32 byte octet string and post 
pend that to the 32 byte r hash string.  In the asn1 case, you just end 
up reversing that - OS2I for the R value and stick it into a standard 
X9.62 ASN1 Sequence of Integer formation.

That has a great advantage in that no one has to write a new parser for 
signatures.  ECSDSA on the wire (keys, signatures, etc) looks the same 
as ECDSA.  It's only when you get into the implementation details of r 
as a hash value and s as an integer for ECSDSA vs r as an integer and s 
as an integer for ECDSA do you really care.  I deal with that all the 
time with various hardware implementations that produce to-be-encoded R 
and S values all as octet strings.

If you're going to do structure twiddling and I really hope you don't, 
then the obvious way of doing this is to  do it as OCTET STRING (r || 
I2OS(s)) rather than a sequence of different values. Why force the 
parser to work that hard?  You could even skip the inner encoding and go 
straight to BITSTRING(0 extra, r || I2OS(s)).

Unless you have grave misgivings about this (and an explanation of why 
this is a problem), then leave the encodings alone.  It triggers more 
work than you can imagine downstream.

Mike


_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix