Subject: [jose] IANA Registration issue

From: "Jim Schaad" <[email-masked]>
Date: Sat, 24 Jan 2015 20:16:07 -0800

In going through the IANA registrations for the
draft-ietf-jose-json-web-algorithms document, I found something that I had
missed the last time that I reviewed the documents and has probably been
there for some time.

All of the signing algorithms point to section 3.1 for the reference column.

All of the key management functions until A128GCMKW point to section 4.1 for
the reference column

The rest of the key management functions point to sections 4.7 or 4.8.

All of the content encryption algorithms point to section 4.1 for the
reference column.

Should we request a change to make this consistent and point  A*GCMKW and
PBSE2-* to point to section 4.1 in the reference column and request an
editor's note to this effect?

Jim

---

From: Mike Jones <[email-masked]>
Date: Sun, 25 Jan 2015 23:03:31 +0000

I agree that there's an inconsistency that we should address, but I'd actually suggest a different change.  Sections 3.1 and 4.1 are overview sections just listing the algorithm identifiers, whereas sections 3.2-3.6 and 4.2-4.8 define the actual algorithms.  If we make a change, I'd suggest that the registrations refer to the actual section defining the algorithm (as is already done for A*GCMKW and PBES2-*).  Specifically, I'd have HS* refer to section 3.2, RS* to 3.3, ES* to 3.4, RSA1_5 to 4.2, RSA-OAEP* to 4.3, etc.  If people agree with this change, which I believe would make the section references in the registry more useful, I can work with IANA and the RFC Editor to make the corrections.

Thanks for looking at the details, Jim.

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Saturday, January 24, 2015 8:16 PM
To: [email-masked]
Subject: [jose] IANA Registration issue

In going through the IANA registrations for the draft-ietf-jose-json-web-algorithms document, I found something that I had missed the last time that I reviewed the documents and has probably been there for some time.

All of the signing algorithms point to section 3.1 for the reference column.
All of the key management functions until A128GCMKW point to section 4.1 for the reference column
The rest of the key management functions point to sections 4.7 or 4.8.
All of the content encryption algorithms point to section 4.1 for the reference column.

Should we request a change to make this consistent and point  A*GCMKW and PBSE2-* to point to section 4.1 in the reference column and request an editor's note to this effect?

Jim

---

From: John Bradley <[email-masked]>
Date: Sun, 25 Jan 2015 20:45:03 -0300

I am OK with that.

> On Jan 25, 2015, at 8:03 PM, Mike Jones <[email-masked]> wrote:
> 
> I agree that there’s an inconsistency that we should address, but I’d actually suggest a different change.  Sections 3.1 and 4.1 are overview sections just listing the algorithm identifiers, whereas sections 3.2-3.6 and 4.2-4.8 define the actual algorithms.  If we make a change, I’d suggest that the registrations refer to the actual section defining the algorithm (as is already done for A*GCMKW and PBES2-*).  Specifically, I’d have HS* refer to section 3.2, RS* to 3.3, ES* to 3.4, RSA1_5 to 4.2, RSA-OAEP* to 4.3, etc.  If people agree with this change, which I believe would make the section references in the registry more useful, I can work with IANA and the RFC Editor to make the corrections.
>  
> Should we request a change to make this consistent and point  A*GCMKW and PBSE2-* to point to section 4.1 in the reference column and request an editor’s note to this effect?
>  
>  
> Jim
>  
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Mike Jones <[email-masked]>
Date: Tue, 27 Jan 2015 17:14:02 +0000

Assuming we’re going to make this change to have the registry entries refer to the actual section numbers where the algorithms are defined, rather than overview sections, addressing the issue that Jim pointed out, to make like easier for the RFC Editor, I applied the changes to the attached document.  Jim, Karen, or Kathleen – are we good to send this to the RFC editor, before they start their actual editing?  The diffs are below.

                                                            -- Mike

1977c1977
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.2 of [[ this document ]]
1985c1985
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.2 of [[ this document ]]
1993c1993
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.2 of [[ this document ]]
2001c2001
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.3 of [[ this document ]]
2009c2009
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.3 of [[ this document ]]
2027c2027
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.3 of [[ this document ]]
2035c2035
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.4 of [[ this document ]]
2043c2043
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.4 of [[ this document ]]
2051c2051
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.4 of [[ this document ]]
2060c2060
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.5 of [[ this document ]]
2079c2079
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.5 of [[ this document ]]
2088c2088
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.5 of [[ this document ]]
2096c2096
<    o  Specification Document(s): Section 3.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 3.6 of [[ this document ]]
2104c2104
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.2 of [[ this document ]]
2112c2112
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.3 of [[ this document ]]
2121c2121
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.3 of [[ this document ]]
2139c2139
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.4 of [[ this document ]]
2147c2147
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.4 of [[ this document ]]
2155c2155
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.4 of [[ this document ]]
2163c2163
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.5 of [[ this document ]]
2171c2171
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.6 of [[ this document ]]
2190c2190
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.6 of [[ this document ]]
2199c2199
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.6 of [[ this document ]]
2208c2208
<    o  Specification Document(s): Section 4.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 4.6 of [[ this document ]]
2277c2277
<    o  Specification Document(s): Section 5.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 5.2 of [[ this document ]]
2286c2286
<    o  Specification Document(s): Section 5.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 5.2 of [[ this document ]]
2305c2305
<    o  Specification Document(s): Section 5.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 5.2 of [[ this document ]]
2313c2313
<    o  Specification Document(s): Section 5.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 5.3 of [[ this document ]]
2321c2321
<    o  Specification Document(s): Section 5.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 5.3 of [[ this document ]]
2329c2329
<    o  Specification Document(s): Section 5.1 of [[ this document ]]
---
>    o  Specification Document(s): Section 5.3 of [[ this document ]]

From: John Bradley [mailto:[email-masked]]
Sent: Sunday, January 25, 2015 3:45 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]
Subject: Re: [jose] IANA Registration issue

I am OK with that.

On Jan 25, 2015, at 8:03 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                            -- Mike

From: jose [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Saturday, January 24, 2015 8:16 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [jose] IANA Registration issue

Jim

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 Jan 2015 20:54:17 -0500

On Tue, Jan 27, 2015 at 12:14 PM, Mike Jones
<[email-masked]> wrote:
> Assuming we’re going to make this change to have the registry entries refer
> to the actual section numbers where the algorithms are defined, rather than
> overview sections, addressing the issue that Jim pointed out, to make like
> easier for the RFC Editor, I applied the changes to the attached document.
> Jim, Karen, or Kathleen – are we good to send this to the RFC editor, before
> they start their actual editing?  The diffs are below.

I'm fine with the change if Jim and Karen agree.

I went through the new version of the draft attached to verify that
each of the new references does point back to the correct section as a
second set of eyes (hoping to reduce future errata) and did not find
any errors.

Thanks,
Kathleen

> I agree that there’s an inconsistency that we should address, but I’d
> actually suggest a different change.  Sections 3.1 and 4.1 are overview
> sections just listing the algorithm identifiers, whereas sections 3.2-3.6
> and 4.2-4.8 define the actual algorithms.  If we make a change, I’d suggest
> that the registrations refer to the actual section defining the algorithm
> (as is already done for A*GCMKW and PBES2-*).  Specifically, I’d have HS*
> refer to section 3.2, RS* to 3.3, ES* to 3.4, RSA1_5 to 4.2, RSA-OAEP* to
> 4.3, etc.  If people agree with this change, which I believe would make the
> section references in the registry more useful, I can work with IANA and the
> RFC Editor to make the corrections.
>
>
>
> editor’s note to this effect?
>
>
>
>
>
> Jim
>
>
>

-- 

Best regards,
Kathleen

---

From: Karen ODonoghue <[email-masked]>
Date: Wed, 28 Jan 2015 09:48:49 -0800

I'm fine with this, but I defer to Jim given that he raised the initial 
issue.

Karen

---

From: Mike Jones <[email-masked]>
Date: Wed, 28 Jan 2015 18:39:58 +0000

Done.  Thanks for flagging this area for improvement, Jim.

From: Jim Schaad [mailto:[email-masked]]
Sent: Wednesday, January 28, 2015 10:14 AM
To: Mike Jones
Cc: 'Kathleen Moriarty'
Subject: RE: [jose] IANA Registration issue

Go ahead and send this update to the rfc editor.

Jim

From: Mike Jones [mailto:[email-masked]]
Sent: Tuesday, January 27, 2015 9:14 AM
To: Jim Schaad; [email-masked]<mailto:[email-masked]>
Cc: Kathleen Moriarty
Subject: RE: [jose] IANA Registration issue

                                                            -- Mike

1977c1977
1985c1985
1993c1993
2001c2001
2009c2009
2027c2027
2035c2035
2043c2043
2051c2051
2060c2060
2079c2079
2088c2088
2096c2096
2104c2104
2112c2112
2121c2121
2139c2139
2147c2147
2155c2155
2163c2163
2171c2171
2190c2190
2199c2199
2208c2208
2277c2277
2286c2286
2305c2305
2313c2313
2321c2321
2329c2329

From: John Bradley [mailto:[email-masked]]
Sent: Sunday, January 25, 2015 3:45 PM
To: Mike Jones
Cc: Jim Schaad; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] IANA Registration issue

I am OK with that.

                                                            -- Mike

Jim