draft-ietf-cose-cmac to the WG. (Timestamp ~05:51 in recording)draft-ietf-cose-cmac GitHub repository. (Timestamp ~08:37 indraft-ietf-cose-split-signing-algs on the mailing list. (Timestampdraft-ietf-jose-pqc-kemdraft-liao-cose-c509-revocationIP doing introductions.
Status of WG documents
Draft link
Presentation slides
BS presenting.
BS (p2): Summary of registrations, document updates, and open issues.
BS: Feedback around TBA codepoint numbers? Would help with examples. No
need for <24.
MJ, hat off: Think NIST is preferable over GitHub reference.
CB: On codepoints. We should use "early allocation" more. We're
approximately there. Not sure we discussed key length and tag length;
will need to discuss number space.
BS: Any number >30 is appropriate, even for 96bit tag length.
MJ: Drafts often request assignments of some size (eg. "2-byte range").
BS: Ok
Draft link
Presentation slides
EL presenting.
EL: The document got adopted by the WG. Submitted v -01. Ongoing
discussion with Ilari.
EL: A number of updates done
EL: No architectural changes since IETF 124
EL: Discussion with Ilari: Best way to handle large messages, want
compatibility with existing verifiers.
EL: COSE_Sign_Args is not self-contained. Should we add optional 'kid'
and data members?
EL: We have implementations; we need more feedback to update the draft.
Some applications are using this already (e.g., wwWallet). Then WG Last
Call.
MJ (as author): Agree that would be unnecessary and unnatural to put
everything into signing args, especially not copy the large data.
IP: Who has read the latest version of the draft?
(1 person)
IP: read a version?
(a few more people)
IP: Implementation status?
EL: The specification defines two roles. We have one implementation for
each role. Not everything from the final draft are impleented.
IP: Early for WG Last Call now. I'd like more reviews and feedback. But
progress are good.
IP: Volunteers to review?
Hannes Tschofenig, John Bradley.
IP: Will ask on list for more.
Draft link
Presentation slides
TR presenting
TR: This was in the JOSE WG for a lot of time. Many comments were
addressed there. Now it focuses only on COSE.
TR: It uses the three possible modes of ML-KEM, and it is independent of
HPKE
TR: Showing building blocks and details.
TR: Supports two modes, and multiple algorithms. COSE has HPKE, but LAKE
needs this work
TR: Requesting the COSE WG to adopt this, then it should already ready
for WG Last Call, given the work already happened in JOSE.
IP: Who read? (3 people)
IP: Thoughts or concerns?
RN, LAKE co-chair: read old version. We will need eventually something,
need flexibility. COSE right group. Offer to review.
IP: JPM gave me the pointers to read there.
GS (on chat): +1 for adoption, this work is needed for LAKE
IP: Looks like some in-group support, can run by mailing list.
Draft link
Presentation slides
CB presenting
CB: New Keccak-based algorithms are available. We need them registered
in COSE. And IRTF could not make Recommended entries when it entered
them; this document can update that.
CB: 9161 sketched the algorithms ("this is so trivial, why don't you do
that"), now we do do that.
CB: KMAC is original Kesshak-based MAC, (????). TurboSHAKE reduces
number of rounds, KMAC was maybe ovely careful. Relevant for constrained
devices for speed. KT (Kangaroo Twelve) divides input into tree,
allowing parallelization. Not so important for constrained devices. Kept
those 3 from alrger set (could look at other ones, but these look
relevant).
CB: We need reviews (some came in already); we plan a revision, then
we'll ask for WG adoption.
IP: Who read? (2 read)
Reviewers? Alex, Hannes, Tiru, Chris, Emil
Draft link
Presentation slides
DO presenting
DO: Defining the use of the ASCON standard in COSE. The standard has an
encryption algorithm, a hash function, and 2 XOFs.
DO: Two primitives integrated matter b/c same permutation function
allows saving memory footprint. ASCON generally saves power. Introducing
3 modes.
DO: Added use for the hash algorithm. Added use in COSE MAC
DO: AIU no direct way to assign algorithm number to HKDF itself, only to
usage such as direct-encryption or ECDH. Currently, only kept encryption
and direct+, but to-do list on p5.
DO: This was covered by a project at the Hackathon. 3 open source
repositories. One was a PR against the repository of the COSE WG.
IP: Interested? 5 hands
IP: Read latest version? few people.
IP: Implementations?
DO: Integrated existing C library into C libraries. Let's talk about
more languages in hackathon.
DO: At the application layer, we used CoAP and OSCORE.
IP: Measured improvements?
DO: No benchmarks taken here.
HT: Student worked on this for DTLS. Performance was worse b/c of
hardware acceleration for existing algorithms. Sure that will change.
TR: AIU optimized for IoT w/o HW acceleration.
DO: No, you can design on SW or HW. ASCON is designed to also save space
on silicon (~30% saving).
CA (on chat): Hannes: No need for dedicated hardware, it's fast eg. on
RISCV when using bitmanip extension already.
IP: Next step is reviewing. Volunteers: Christian, Hannes, Tim(?), Quynh
Dang, Tiru
Draft link
Presentation slides
RH presenting
RH (p2): We have c509 certificates but that's only a piece of PKI. In
particular compact revocation is missing (with CRL or OCSP). That comes
in this document.
RH (p3): Summary of contributions.
RH (p4): Design principles (preserve from previous design, with some
deviations for optimization)
RH (p5-6): The proposed design enables more optimizations than just a
straight mapping from ASN.1 to CBOR. Examples.
RH (p7): Defined structures for CRL.
RH (p8): Comparison of current and proposed CRL design.
RH (p9): Comparison of current and proposed OCSP design.
RH (p10): ToC of the draft. An appendix includes examples together with
statistics and size comparisons.
RH (p11): Size reduction shown for CRL.
RH (p12): Size reduction shown for OCSP.
RH (p13): Next steps: confirm that the design direction is good and
discuss optimization choices (that could be pushed further); prototype
implementations; refine IANA registrations; add security considerations.
HT: Seems logical after certificate compression. Haven't seen, in IoT
space, anyone using CRLs or OCSP; instead, deploy device management.
Whole setup different. How do you see that working for those ignoring
the device management approach? Wouldn't such users use status list
instead? That is recent work that deals with disadvantages of CRLs and
OCSP.
RH: Why not? Missing our work. Lijun want to use it. But comparing to
existing solutions would be good.
HT: Don't think people don't use them b/c they're too large – but most
their uses are device-to-cloud, and changes can just be sent through
there. Might be worthwhile to check back with companies.
RH: Worth exploring.
GS: Great work. It makes sense as building up on other things that have
been standardized. It's aligned with the Charter. There are multiple
ways to handle certificate revocation. Lijun is very focused on using
C509 in industrial deployments (especially in the automotive space -
Nio) and they have interest in using this. I support this work.
IP: Need to check if in charter. But it looks like a logical
continuation to C509 certificates.
Chris Lemons: Some IETFs ago, some volunteered to read and feedback
Composite Claims. Would love to read more feedback. Especially also
relevant for MOQ (Media Over QUIC) authorization model.
CI: Reading HPKE draft. JOSE document was incoherent in its algorithm
selection (lacking combinations). How much alignment do you want between
JOSE/COSE HPKE?
MJ as editor of drafts: in JOSE, we sorted that (remomved 2 key
establishment algorithms w/ ChaCha/Poly, as these made no practical
sense without content algorithms). Corresponding integrated encryption
algorithms stayed. Back at IESG now. Not as much churn as it might have
seemed. In COSE, registereed ChaCha/Poly content algorihtms, so
motivation from there does not apply. Other than that, algorithm set is
aligned.
HT: There's different needs for the registration of algorithms between
the different WGs. For some groups, a registration may be a stratch;
some are not needed in JOSE and they were removed. The underlying design
is similar. It's just that the HPKE-related work started in JOSE and
then it was extended to cover COSE too. Similar issues come up, then
evolving into encoding. But hope, as MJ, that this is advancing quickly.
CI: Hearing that I will advance it as you collectively do not intend any
change to algo registration.