hi Ben. comment inline. > From: Ben Campbell [mailto:b...@nostrum.com] > Sent: Wednesday, June 26, 2013 1:04 PM > > Hi Michael, > > Thanks for the continued responses. A few more comments inline. I deleted > sections that did not seem > to need further comment. In summary, all of my concerns are resolved except > for the crypto profile > question. > > Thanks! > > Ben. > > On Jun 26, 2013, at 2:00 PM, Michael Thornburgh <mthor...@adobe.com> wrote:
[...] > >>> yes, endpoints need a common cryptography profile to interoperate. there > >>> is no repository for > >> crypto profile documentation at this time. currently, there is one defined > >> cryptography profile > (the > >> one used for Flash communication) that is not publicly documented, because > >> i do not yet have > >> permission to publish it. i (meaning me personally) hope that a memo > >> documenting the > >> crypto/application profile for Flash communication (as being a widely > >> deployed and used profile for > >> RTMFP) would also be published someday as an I-D and hopefully an > >> Informational RFC. > >> > >> I understand the issue about permission to publish, but does this document > >> serve its purpose until > you > >> are ready to publish the crypto profile? Ideally they would be published > >> together and this document > >> would reference that one. Do I infer correctly that there is no way > >> someone could create an > >> implementation that interops with Adobe products based on the documents > >> available at this time? > > > > additional documentation is needed to interoperate (at the application > > layer) with the Adobe > products that implement RTMFP. i hope that the successful publication of this > memo will help me in > getting the necessary approval to publish the higher layer details of Adobe's > RTMFP ecosystem. > > > > the situation is analogous to having published TCP, but there's a lot more > > you need to know to talk > to a web server with HTTPS (like TLS and HTTP). it's still useful to know > how TCP works, and plenty > more to do with it than talk to web servers. > > I don't think that's a fair analogy. I can use TCP for many purposes other > than talking to web > servers. It can even be useful all itself. But if I understand correctly, you > can't expect to use > RTMFP _at_all_ until you publish they crypto-profile(s). Is that correct? If > so, a better analogy > would be to publish TLS without any published cryptosuites. > > If I am correct on the inability to use the protocol at all without more > documentation that does not > currently exist, then I think it would be reasonable to put a clearly worded > assertion to that effect > early in the draft, along with a comment that you intend to publish at least > one crypto profile in the > future. (Perhaps an applicability statement would be helpful here.) interoperating with the Flash ecosystem requires additional documentation. i agree that a better analogy is publishing TLS without any published cryptosuites. using RTMFP requires _a_ cryptography profile. this memo describes the required semantics of a cryptography profile. the first bullet of Section 1.1 "Design Highlights" (which occurs on the first page after the TOC), Section 2.2.3 "Encryption", and the first paragraph of the Security Considerations section all indicate that this protocol defines a general framework for security, and that the application designer chooses/defines the algorithms and data formats to be used within that framework. an application designer could, using only this memo (and knowledge of security and cryptography principles), define her own cryptography profile suitable for her application of RTMFP, and create a correct and useful RTMFP application. since i don't yet have permission, i can't make a commitment in this memo that Adobe will (or intends to) publicly document any additional layers of the RTMFP-in-Flash ecosystem. just for extra clarification: it is my *personal* hope that i will be able to do so in the future. [...] thanks! -michael thornburgh
