Hi Justin, Thanks for the quick response.
On Thu, Feb 26, 2015 at 11:40 AM, Justin Richer <[email protected]> wrote: > On Feb 26, 2015, at 11:04 AM, Kathleen Moriarty < > [email protected]> wrote: > > > Hello, > > I reviewed draft-ietf-oauth-dyn-reg-management, which reads well and I > just have a few questions and suggestions below that would be good to > address prior to IETF last call. > > Section 1.3 > Bullet D might be easier to read as a list within the bullet. > > > OK, I’ll try that and see how it renders in the various output formats. > Lists-within-lists don’t always play nice in my experience, hence the > paragraph format, but we’ll see what it looks like. I agree that it’s an > intimidating block of information there. :) > > Thanks for playing with this, it might help. > > Section 2 > This is something I don't recall offhand and may be in place in another > draft, so a pointer would be great. Is there an MTI set for one of the > recommended cipher suites in the TLS & DTLS BCP to ensure interoperability > (but also allow for algorithm agility)? If not and there is a reason, > please explain. > See section 4: https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/ > This is not the right draft to add this content, but I'd like to know if > it is covered somewhere or doesn't need to be for some reason. TLS > requirements should point to that draft (assuming one exists) so there is > only one place to update if needed for any specific requirements to OAuth. > > > This is a copy of the text found in > https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-24#section-5 > Yes, I realized that when I read it, thanks. > > We basically just want to say “use an encrypted channel” and point to the > best guidance there is out there at the time. There shouldn’t be any > specific requirements for OAuth. Maybe in the future the IETF could have a > standard single reference for transport protection that can be included > a-la the 2119 definitions? > I brought this up as I read a few drafts for last week's telechat, one was the BCP for TLS. As a result, it got me digging into a few drafts to see how it is getting used. Hence, me noticing this possible issue in this review. The TLS protocol itself defines a large number of cipher suites for use that are registered with IANA (defined per version, but you have to dig into the referenced specs to see when each was added). Then a number of protocols that use TLS define an MTI to ensure interop between implementations, but typically have an explicit statement to allow for algorithm agility. The recent drafts seem to select one of the recommended cipher suites from the list int he new TLS BCP. Does use of TLS show up in an earlier draft or published OAuth RFC where this would be appropriate to define? How do implementations ensure interop now? Maybe that will help answer this question. > IANA Considerations: > The shepherd report says that there are no actions for IANA, so this needs > to be updated as the draft is the specification required to add two new > entries to an existing registry, established by the parent document. It > does require DE review on the mailing list: [email protected] > If that has been done, then a pointer to the archive would be helpful. > > Thank you. > > -- > > Best regards, > Kathleen > > > Thanks for the review, > — Justin > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
