Even so, given that we want specific identifiers to be allocated in specific
numeric ranges, it seems less error-prone to include the suggested values to
register in the specification. If there are actual conflicts at registration
time, these suggested values would obviously be changed anyway. In my
experience, both IANA and the RFC Editors are happiest when as much as possible
is in final form when they begin to process the documents. Obviously either
way would work.
-- Mike
From: COSE [mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Sunday, July 31, 2016 1:34 PM
To: Mike Jones <[email protected]>; 'Justin Richer'
<[email protected]>; 'cose' <[email protected]>
Subject: Re: [COSE] Adoption of RSA and alternative algorithms
You misunderstand the process. The RFC editor replaces the TBDs with the IANA
assigned values just before Auth48
From: COSE [mailto:[email protected]] On Behalf Of Mike Jones
Sent: Sunday, July 31, 2016 12:34 PM
To: Jim Schaad <[email protected]<mailto:[email protected]>>; 'Justin
Richer' <[email protected]<mailto:[email protected]>>; 'cose'
<[email protected]<mailto:[email protected]>>
Subject: Re: [COSE] Adoption of RSA and alternative algorithms
The problem with this, unless I misunderstand the process, is that it will
result in an RFC containing TBD# for the assignments, rather the actual
numbers, which is less useful to developers. I think it would be better for
the RFC to contain the assigned numbers.
From: COSE [mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Sunday, July 31, 2016 12:30 PM
To: Mike Jones
<[email protected]<mailto:[email protected]>>; 'Justin
Richer' <[email protected]<mailto:[email protected]>>; 'cose'
<[email protected]<mailto:[email protected]>>
Subject: Re: [COSE] Adoption of RSA and alternative algorithms
Or better, go through the normal IANA registration process to get them
From: Mike Jones [mailto:[email protected]]
Sent: Sunday, July 31, 2016 12:02 PM
To: Jim Schaad <[email protected]<mailto:[email protected]>>; 'Justin
Richer' <[email protected]<mailto:[email protected]>>; 'cose'
<[email protected]<mailto:[email protected]>>
Subject: RE: [COSE] Adoption of RSA and alternative algorithms
Thanks for the info, Jim. Since the numeric assignments are wrong, the first
thing to do for either draft would be to incorporate correct ones.
-- Mike
From: COSE [mailto:[email protected]] On Behalf Of Jim Schaad
Sent: Sunday, July 31, 2016 11:58 AM
To: Mike Jones
<[email protected]<mailto:[email protected]>>; 'Justin
Richer' <[email protected]<mailto:[email protected]>>; 'cose'
<[email protected]<mailto:[email protected]>>
Subject: Re: [COSE] Adoption of RSA and alternative algorithms
From: COSE [mailto:[email protected]] On Behalf Of Mike Jones
Sent: Sunday, July 31, 2016 11:27 AM
To: Justin Richer <[email protected]<mailto:[email protected]>>; cose
<[email protected]<mailto:[email protected]>>
Subject: Re: [COSE] Adoption of RSA and alternative algorithms
Responses inline…
From: COSE [mailto:[email protected]] On Behalf Of Justin Richer
Sent: Friday, July 29, 2016 7:04 AM
To: cose <[email protected]<mailto:[email protected]>>
Subject: [COSE] Adoption of RSA and alternative algorithms
Hi all, hope that everyone is recovering from Berlin. As discussed in the
meeting last week, the working group is considering additional work on RSA and
other algorithms in the COSE messages framework. These would be published in a
document separate from the core draft that is now on its journey to RFC-land.
The chairs would like to gauge the sentiment of the working group on a number
of items related to this proposed work. Please respond with your answers to the
list.
1) Do you think it’s necessary or worthwhile to define RSA and other additional
algorithms in the COSE messages framework?
A) Yes, we should do an RSA/other-algs document
B) No, we shouldn’t do an RSA/other-algs document
C) Yes, but not right now
D) I need more information (please ask what you want to know)
E) I don’t give a flying rat whether this gets done or not
A) Yes, we should do an RSA document now. These are needed now. Other
algorithms can come later and be registered then.
2) If the work is adopted, where should it be done?
A) Here in COSE (we’ll keep the group open for this item)
B) In other working group (please specify where; note that ACE is a possible
option)
C) I need more information (ask what you want to know)
D) I don’t give a flying rat where this happens
A) Here in COSE (we’ll keep the group open for this item)
3) If the work is adopted, which draft is a good starting point?
A) Jim’s draft: https://tools.ietf.org/html/draft-schaad-cose-alg-01
B) Mike’s draft: https://tools.ietf.org/html/draft-jones-cose-rsa-00
C) Some other draft (please tell us which one it is or offer to write it
yourself)
D) I need more information (ask what you want to know)
E) I don’t give a flying rat which document we start with
B) Mike’s draft: https://tools.ietf.org/html/draft-jones-cose-rsa-00 because it
already has the numeric assignments in place and doesn’t have any other
algorithms besides the RSA algorithms
The numeric assignments are wrong as I have reordered the set of algorithms
after the fork occurred.
Jim
We’re going to keep this thread open for two weeks at the AD’s request, and the
chairs will try to make a consensus call at the end of that time period.
Thank you,
— Justin & Kepeng, your COSE chairs
\. - - .
' _ , -`.
' _,' _,'
' ,-' _/
' ,-' \ _/
' ,' \ _'
' ' _\'
' , _,-' \ _________
\,_,--' \ \\_______\<smb://_______/>
\ \\+=+=+=+\<smb://+=+=+=+/>
\ \\=+=+=+=\<smb://=+=+=+=/>
\ \\+=+=+=+\<smb://+=+=+=+/>
\ \\=+=+=+=\________
\ \\+=+=+=+____----))
\ \`---------.)))\\
\ ||+=+=+=+=+=\\ /\\
\ ||___________\\/ \\
\ ||------------\\
ejm \|| \\
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
