Subject: Re: [Suit] draft-atkins-suit-cose-walnutdsa

From: Derek Atkins <[email-masked]>
Date: Tue, 02 Jul 2019 10:15:06 -0400

Dean Janos,

Sorry for the delay in responding; I've been on the road for most of
June and it's taking me a while to catch up on the ~10,000 emails that
piled up while I was (mostly) offline.

We have customers who are looking to use this technology today, so we
would like to do it in a standard way that others could understand.
Personally, I'm fine with an Informational (instead of Standards-track)
publication if that would make people happier.  Even so, the RFC Editor
would still require approval from this WG as it is within their (the
WG's) area.

There is no rule requiring the CFRG to approve informational documents.

Thanks,

-derek

Janos Follath <[email-masked]> writes:

> Dear Derek,
>
> I think that before standardising a new cryptographic scheme in IETF it
> would be prudent to have it approved by CFRG first, I believe this
> might even be a rule.
>
> If I remember correctly, then the Hash-based signature proposals have gone
> through some kind of an approval process. Has the CFRG approved WalnutDSA
> too?
>
> Regards,
> Janos
>
>> [Suit] draft-atkins-suit-cose-walnutdsa     
>
>>
>
>>      Derek Atkins <[email-masked]>
>>      Tue, 14 May  2019 13:05 UTC
>
>>
>> Hi everyone,
>>
>> I have submitted a new draft on how to use WalnutDSA in COSE, targeting
>> SUIT as a viable use-case.  WalnutDSA is in use for a secure boot
>> solution now; specifying how to use it in a standard way would help
>> others leverage the technology (or at least ensure there are no
>> conflicts with others).
>> 
>> I have tried to follow the framework of the Hash-based signature
>> integration (with Russ' approval).
>>
>> -derek
>> -- 
>>        Derek Atkins                 617-623-3745
>>        [email-masked]             www.ihtfp.com
>>        Computer and Internet Security Consultant
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Jul 2019 11:22:49 -0400

Derek, looking at the IANA Considerations of
draft-atkins-suit-cose-walnutdsa, it seems that you need a number in:

1) COSE Algorithms -- registry
2) COSE Key Types -- registry

and several in the
3) COSE Key Type Parameters -- registry

https://www.iana.org/assignments/cose/cose.xhtml#algorithms

For the first, you can have:
    Integer values greater than 65535	Expert Review

And the other two are Expert Review anyway, no specification required!
You are even listed as one of the experts for COSE Key Types :-)

{If my reading is correct, you can also use strings longer than 2-bytes
without registration with IANA, but that has an operational (maintaining
legacy code) and bytes-on-the-wire impact should you be allocated a shorter
code later on}

You could also ask for early allocation via the COSE WG, but that probably
requires the document to be adopted first!

That's what I would do: just ask for the values via Expert Review, and live
for now, with the a five-bye (encoded) COSE Algorithm code, if your market
need is urgent.

    > would still require approval from this WG as it is within their (the

yes, if you went ISE, which would still take awhile.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Derek Atkins <[email-masked]>
Date: Wed, 31 Jul 2019 11:12:19 -0400

Michael,

Again, sorry for the delay in responding.  I've had a lot of $DAYJOB
deadlines which have taken over and some things have fallen through the
cracks.  Too many balls in the air, so to speak.

Comments are inline below..

> 3) COSE Key Type Parameters -- registry

Correct.

> You are even listed as one of the experts for COSE Key Types :-)

Yes, I know I am one of the experts for these registries.  However, I
feel I must recuse myself from approval of these.

> legacy code) and bytes-on-the-wire impact should you be allocated a shorter

Yes, which is another reason I'd rather get something right.

> requires the document to be adopted first!

Does it?  Or does the WG just need to approve of the document going
through any of the publication processes?

> for now, with the a five-bye (encoded) COSE Algorithm code, if your market

Yes, I could just request the entries in the registry.  However, I am
trying to be a good netizen; I want to have a document that people can
look at to understand what the registry items mean.

> yes, if you went ISE, which would still take awhile.

I am fine going through the ISE, however I suspect that the IESG in
their conflict review would then go and ask this WG about it.  So I
wanted to bring it up here, first.  What is your definition of "awhile"?

Thanks,

-derek

---

From: Michael Richardson <[email-masked]>
Date: Wed, 31 Jul 2019 15:38:05 -0400

> feel I must recuse myself from approval of these.

Yes, obviously, but the point is that you will know how to ask nicely :-)

    >> You could also ask for early allocation via the COSE WG, but that
    >> probably requires the document to be adopted first!

    > through any of the publication processes?

If the document isn't adopted, then I don't think the WG chairs can ask the
AD to approve.  I think that adoption is the only required step; your
document could take awhile to progress.  IANA will check back on progress for
the early allocation, to make sure the document is still of interest.

    >> That's what I would do: just ask for the values via Expert Review, and
    >> live for now, with the a five-bye (encoded) COSE Algorithm code, if
    >> your market need is urgent.

    > look at to understand what the registry items mean.

While you don't have to provide a specification for Expert Review, I think
that if you *do* that it will get recorded.  If you later on get a 1-byte
code allocated then, it's code complexity, but it's not too terrible, I think.
At some point, your constrained devices will only use the 1-byte code,
and your non-constrained devices will continue to be tolerant of both.

    >> Derek Atkins <[email-masked]> wrote: > We have customers who are
    >> looking to use this technology today, so we > would like to do it in a
    >> standard way that others could understand.  > Personally, I'm fine
    >> with an Informational (instead of Standards-track) > publication if
    >> that would make people happier.  Even so, the RFC Editor > would still
    >> require approval from this WG as it is within their (the > WG's) area.
    >> 

    > wanted to bring it up here, first.  What is your definition of

Given the conflict review and the typical length of the RFC editor Production
queue, I would say you are looking at a year before AUTH48, but the early
allocation could occur much sooner.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 31 Jul 2019 19:11:02 -0500

> document could take awhile to progress.  IANA will check back on progress for

I think so, too.

> the early allocation, to make sure the document is still of interest.

Yes, a one-year extension with just the chairs' approval and subsequent
ones with the IESG's approval.

> that if you *do* that it will get recorded.  If you later on get a 1-byte

I think so, too.

>     > their conflict review would then go and ask this WG about it.  So I

My understanding is that Adrian will be asking that even before the
document gets far enough to need an IESG conflict review.

> allocation could occur much sooner.

Adrian has been pressing the IESG to adhere better to the 4-week timeline
for conflict review responses (modulo IETF meetings, etc.), but given the
xmlv3 cutover and C238 breaking loose, it does seem reasonable to expect
things to get backed up a bit.

-Ben