small correction: the word "not" in "n is not the size of the
prime-order subgroup" should obviously not be there
On 2020-11-13 9:57 a.m., Rene Struik wrote:
Hi Goran:
I had a brief look at your slides posted on the Ericsson github page [1]:
- Side #11, text marked in red: the answer to this question is "yes",
with small correction: n is not the size of the prime-order subgroup,
not the curve order (which is h*n)
Note: for curves in question, both n and h*n have the same byte-length
- Slide #11, last line: ECDSA is defined in FIPS Pub 186-4
Note: draft FIPS Pub 186-5 stipulates that hash SHAKE has fixed output
size 256 or 512 bits (see also PKIX-related blurb in lwig draft, which
refers to RFC 8692 that is consisent with this. See
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-11.2
- Slide #13: the lwig draft requests registration of OIDs id-Wei25519
and id-Wei448, based on IETF Last-Call comments SecDir. Those would
end up with lefthandside column of this slide
See:
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-12.1
As to point compression: PKIX specifies this using the SEC1 format.
See https://tools.ietf.org/html/rfc5480#section-2.2
Note: with Wei25519, SEC1 encoding yields 33-octet strings, while
"squeezed" MSB/msb-order yields 32-octet strings (for Wei448, there is
no difference). See also definitions in (c) below.
In either case, there is a 1-1 map between these, so if, e.g., LAKE WG
wishes to shave-off one byte over-the-air, one could do so and convert
back in light-weight preprocessing of incoming packet
See (a) and (b) below for details; see (c) below for definitions.
(a) ECDSA25519 signatures:
Signature: pair (r,s), where r and s are 32-octet integers, in tight
MSB/msb-order
Notes:
-this uses the same encoding principles as in same format as
ECDSA/P-256/SHA-256
- "tight" means that integers r and s are represented as fixed-size
strings (so, no leaving out of leading zero-octets)
-with Wei25519, n is 253-bit integer (i.e., 32-octet), see also
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-E.3
For description, see
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.3
For PKIX-related blurb, see
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-11.2
(b) ECDSA448 signatures:
Signature: pair (r,s), where r and s are 56-octet integers, using same
encoding principles as ECDSA/P-256/SHA-56
Notes:
-this uses the same encoding principles as in same format as
ECDSA/P-256/SHA-256
- "tight" means that integers r and s are represented as fixed-size
strings (so, no leaving out of leading zero-octets)
-with Wei448, n is 446-bit integer (i.e., 56-octet), see also
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-M.3
For description, see
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-4.4
For PKIX-related blurb, see
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#section-11.2
(c) Unambiguous definitions:
For definition curve nomenclature, see
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-B.1
For definition of bit-length, byte-length, see
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-I.1
For definition of point encodings, including "squeezed"
representation, see
https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-13#appendix-I.8
Ref:
https://github.com/EricssonResearch/CBOR-certificates/blob/master/IETF-109-COSE-CBOR-Certificates.pdf
On 2020-11-13 8:38 a.m., Göran Selander wrote:
Dear chairs and all,
We uploaded slides for agenda item #3 (CBOR Certificates) of the COSE
WG meeting to the current Github repo:
https://github.com/EricssonResearch/CBOR-certificates
<https://github.com/EricssonResearch/CBOR-certificates>
https://github.com/EricssonResearch/CBOR-certificates/blob/master/IETF-109-COSE-CBOR-Certificates.pdf
<https://github.com/EricssonResearch/CBOR-certificates/blob/master/IETF-109-COSE-CBOR-Certificates.pdf>
Note that -03 is not submitted yet, will be when the submission tool
opens again, but the Editor’s copy on the Github is up-to-date:
https://ericssonresearch.github.io/CBOR-certificates/draft-mattsson-cose-cbor-cert-compress.html
<https://ericssonresearch.github.io/CBOR-certificates/draft-mattsson-cose-cbor-cert-compress.html>
Looking forward to a good discussion!
Best regards
Göran
On 2020-11-03, 18:06, "COSE" <[email protected]> wrote:
Dear all,
Here is a preliminary agenda for our IETF 109 session. Please let us
know if you have any questions or concerns related to it.
As a reminder the COSE WG session is scheduled for 60 minutes on
Monday, 16 November starting at 7:30 UTC.
```
COSE WG Agenda
IETF 109 - Virtual/Meetecho
2020-11-16 @ 7:30 UTC
## 0. Administrivia (Chairs)
* NOTE WELL
* Bluesheets
* Jabber + Minutes
* Agenda Bartering
## 1. Document Status (Chairs)
## 2. Countersignatures
## 3. Cert Compression
## 4. Chartering (Chairs)
## 5. AOB
```
--
Matthew and Ivaylo
COSE Chairs
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
--
email:[email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
--
email: [email protected] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
