FW: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The TransportLayer Security (TLS) Protocol Version 1.2) to Proposed Standard
I should have CC'd IETF on the following. (Thanks Nelson.) --mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Brown Sent: Thursday, February 28, 2008 2:57 PM To: [EMAIL PROTECTED] Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4346-bis (The TransportLayer Security (TLS) Protocol Version 1.2) to Proposed Standard TLS Supplemental Data [RFC4680] was overlooked, e.g. in section 7.4.2. Server Certificate, The server MUST send a certificate whenever the agreed-upon key exchange method uses certificates for authentication (this includes all key exchange methods defined in this document except DH_anon). This message will always immediately follow the server ^--No hello message. Also in section 7.4.7. Client Key Exchange Message, This message is always sent by the client. It MUST immediately ^--No follow the client certificate message, if it is sent. Otherwise it MUST be the first message sent by the client after it receives the ^--No server hello done message. Instead, per [RFC4680], ServerCertificate may follow a server's SupplementalData message. Also, Client Key Exchange follows the client Certificate message and/or the client SupplementalData message, if these messages are sent. [RFC4680] should also be added to the references section. It may be helpful to add SupplementalData to Figure 1 on page 34 of rfc4346-bis as well, marked with an asterisk *, following Figure 1 in [RFC4680]. --mark ___ TLS mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/tls ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
John, I should have responded in my last email: > I think you are being told --by a number of people and in > different ways-- that there is a perception that having to ask > for a license is seen as appreciably more burdensome and, for > various reasons, risky than if a general license is granted > without an application process. My impression is that is a > general perception around the IETF, not just related to your > work or proposal. > > So, rather than (or at least in addition to) telling others to > go consult their lawyers to find out whether they could possibly > work with your licensing requirements, I would encourage you to > go back to your own and see if you can either (i) get the > requirement to formally apply to you for a license removed or > (ii) get a really good explanation as to why no strategy other > than such an application is sufficient to meet your > organizational needs. Sure, I can do that too. I'm a newcomer to the IETF, and sometimes I find myself a bit out of the loop regarding the general perception around the IETF. I appreciate you filling me in. --mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
John, On the one hand, let's just get started figuring out how the promise / request can be made so that it's not a burden to the open source community. I'm asking for input. Maybe a comment in the open-source source code (the way the EAY disclaimers read atop OpenSSL files for example) is sufficient to publicly request the GUL. Maybe that also satisfies the "install" disclosure as well, at least as far as the open source provider is concerned. I'm open to reasonable suggestions here. And I have benefited from Simon's pushback so far. My revised sense is that those who publish source code, such that promises embedded within that source code also get published, don't need to write a postcard. Those who are keeping their source code as a secret will need to notify RedPhone Security of their acceptance of the GUL more explicitly than in source code comments. On the other hand, I want to ask open source providers who accept the GUL to avoid knowingly trafficking in PAS Function implementations. Here's an analogy: PAS Function implementations aren't kiddie porn, but all the same they're not very compatible with public ftp sites, etc. In the analogy I mean this: In some countries, users of PAS Functions could/may be doing something illegal if that user doesn't have a license. I want to ask GUL-compliant open source publishers to discard contributions that implement PAS Functions, e.g. not roll them up into a release. This is my personal opinion of the GUL: IF person X, who doesn't participate in (or know about) the GUL makes a PAS Function, that's RedPhone Security's concern, not any open source provider's. If person X checks PAS Functions into a development/unstable source code tree operated by a GUL licensee, then I'd expect the GUL licensee to just delete that contribution when it's discovered, and not worry any further about it. In my mind, a scenario that violates the GUL would be where person X contributes (checks into source control), and a GUL licensee accepts the contribution, and that licensee functionally tests and approves the PAS Functions (thereby confirming that the contribution performs the PAS Functions described in the GUL), and then that licensee releases the PAS Functions as a stable / blessed build. That seems to me to be a "three strikes and you're out" GUL violation. In saying this, I'm trying to be flexible. I could go farther and try to work out more detailed scenarios that might reduce risk and burden, but I'd just be guessing. Instead, let me stop here and ask for input. Is there burden in putting a comment in source code that recites the RPS GUL, or is the burden in the postcard? I'm open to suggestions on the mechanics for making the GUL promise. Is it risky that a (possibly open source) software provider might accidentally but in good faith cruise through all three strikes with respect to the PAS functions (accept, test and release) and that their GUL might be void until things get patched up with RedPhone Security? Then let me know what risks are of concern so I can try to address them. To be fair, I can see that the open source community probably bears a higher burden to keep PAS Functions out of their source code, so I would like to try to ease the burden of requesting the GUL. So I'd like to work this out, but I will need some clear and direct feedback to get it right. Best regards, mark > -----Original Message- > From: John C Klensin [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 25, 2007 11:23 AM > To: Mark Brown; 'Simon Josefsson' > Cc: [EMAIL PROTECTED]; ietf@ietf.org; [EMAIL PROTECTED] > Subject: RE: Withdrawal of Approval and Second Last Call: draft-housley- > tls-authz-extns > > > > --On Monday, 23 April, 2007 17:17 -0500 Mark Brown > <[EMAIL PROTECTED]> wrote: > > >... > > My understanding is this: The "request" for the GUL implies a > > promise not to implement the PAS Functions. This promise is > > valuable to RedPhone Security. If it's worth it to you to make > > the GUL promise (for whatever reasons, laws, or possibilities > > that you see) then you can make the promise and receive the > > GUL from RedPhone Security. Of course everyone is free to > > make their own decision about whether it's better to make the > > GUL promise or not. But if you don't make the promise, you > > won't get the GUL. > >... > > Mark, with the usual IANAL qualifications, I've seen lots of > general, "you don't need to ask us" licenses that contain "this > license is valid only as long as you refrain from doing the > following things..." language. The most common form of that > language involves provisions about not suing t
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Hi Simon, > It would be useful if you could explore with your lawyers if it is > actually easy for you to avoid problem (1). I'm wondering what > exactly the requirement for implementers to "request" this license > from you gives you. Your text suggest that you will never refuse to > grant the rights in your license to someone who ask, is that right? > If so, what problem would there be in granting the rights immediately > to everyone, without a need to request it from you? > > Is your reason that you want to know who is using your IPR, and open > up a communication channel with them? To solve that concern, you > could write a request that everyone is requested, but not legally > required, to get in touch with you. That would get you into contact > with the majority that is positive about talking with you, and you > wouldn't need to hear from people who doesn't want to talk with you. My understanding is this: The "request" for the GUL implies a promise not to implement the PAS Functions. This promise is valuable to RedPhone Security. If it's worth it to you to make the GUL promise (for whatever reasons, laws, or possibilities that you see) then you can make the promise and receive the GUL from RedPhone Security. Of course everyone is free to make their own decision about whether it's better to make the GUL promise or not. But if you don't make the promise, you won't get the GUL. > > Replacing the need to request a license from you with a requirement to > place a comment in header files to make things clear to end users may > be acceptable, possibly barring the problem in the next paragraph. > This is basically the same as giving the rights directly to everyone, > without a need to contact you. So it seems you have already started > leaning towards that solution. (It is important that you do not > require that the comment is placed in all "advertising material", or > similar, or you will run into the problem that the original BSD > license had with GPL-compatibility.) > Making the GUL promise costs no money (that part is free); I hope it doesn't cost anybody any time to _not_ implement the PAS Functions; and I don't want to make the mechanics of making the request / promise cost a lot of time either. But the GUL promise as "valuable consideration" is the cost of the GUL to Manufacturers. As far as I can see, it's not ok to omit this. I hope many people find the offer attractive. As I mentioned, I'm open to suggestions and feedback on the mechanics of making the "request". > Another basic problem is that free software projects may not be able > to agree to your field-of-use limitation in (2) and at the same time > be compatible with license such as the GNU General Public License. > Thus they would never be able to implement tls-authz even without any > support for PAS under your license. I am not certain of this, but I > could ask the Free Software Foundation's lawyers about this -- they > are the copyright holder of GnuTLS which implements tls-authz without > PAS today, and can speak authoritatively about this. I would appreciate if you would follow up with your lawyer(s) on this question. As I've said before, I believe that even if GNUTLS/FSF (for example) made the GUL promise, its software would continue to be "free to use" because only GNUTLS (or whatever parent organization) would be bound to honor that promise. I hope your lawyers will find this to be true. Best regards, mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, Thanks, I'm glad you thought the license was helpful: > From a proprietary perspective, it appears to be a rather permissive > license. It seems to be one of the better ones that I have read > relative to the other licenses in the IETF IPR disclosure list. Kudos > to Mark! I want to speak informally and just kick some ideas around right now. So, disclaimer, For this and other posts to this IETF email list, please understand that I'm speaking for myself and not as an agent of RedPhone Security. Ok. You raise two problems: > However, if I understand the license correctly, it seems incompatible > with free software licenses. The RedPhone license contains: > >"1. General Use License" > >"Upon request, RedPhone Security will provide a worldwide, >nonexclusive, fully-paid, perpetual, royalty-free patent license to >manufacturers who (a) implement the Protocol, (b) acknowledge this >general use license as described in Schedule B, and (c) refrain >from implementing any Protected Assurance System Functions defined >and listed below. This general use license granted to >manufacturers also flows down to sublicensees and users, to permit >end users of these systems (including both client and server >components) to use the Protocol, provided those users do not use >the system as a Protected Assurance System (PAS) as defined in >Schedule A without obtaining an End User License." > > There are two problems here: > > 1) Requires that vendors 'request' the license. It would be > better if the license was given directly to third parties without > any action required by the third parties. > > 2) The restriction of field-of-use (i.e., cannot be used with > PAS) is incompatible with free software norms: implementations > must be usable for any purpose as long as the license is > followed, and several free software licenses does not permit > restrictions like this. Problem 1 seems solvable to me, but I'd like more input. For 2, My goal is this exchange: Manufacturer: "We're requesting the General Use License from RedPhone Security. In exchange, we promise not to implement (or on a per-release basis: we did not implement) the PAS Functions." Each Manufacturer needs to take responsibility only for "his" own actions; any subsequent Manufacturer (alters the code in a way that may or may not be material to the PAS Functions) either voids the license or inherits it or requests their own license -- but that's not "your" problem. A Manufacturer will develop code, test the functionality and release the software. At each of these steps it should be pretty clear if the software being developed, tested and released violates the PAS Functions. ..Doubly clear if the function of the software is to make use of X509 certificates which are marked with a "critical" policy that identifies RedPhone Security (a hard-coded OID ending in .23106 will likely show up in the software). I think a free software provider/clearinghouse could choose to not go beyond the RedPhone Security General Use License with no problem. In the event that some third party contributor made a code contribution "back" to the provider that violated the PAS Functions, simply classify that code-contribution as "buggy" -- and choose to not roll that contribution up into any release. I can imagine a case where a user of free software chooses to start with free software and then obtain a PAS License from RPS and become Manufacturer2. Then the score would be: Manufacturer1: GUL, Manufacturer2: PASL, and both would remain true to their commitments -- no problems. The only problem would be if Manufacturer2 contributed PAS Functions back to Manufacturer1 and then Manufacturer1 rolled those functions in (and tested and released them) under GUL. Back to question 1, I guess the question for me is, Who is making the promise to RedPhone Security? How the promise is communicated is not the main issue. If the preferred OpenSSL approach is to put a legal stuff into comments atop source files which are published for anyone to see, that may be more effective than sending one postcard. This may also help (somewhat) the "on installation" question. If one Manufacturer only releases (presumably tested) source code, then "on installation" for source code could simply be comments atop the source code file. What I want to accomplish is fair warning to downstream users / Manufacturers, so that we can help users steer clear of accidental GUL violations. In summary, for (1) I'd like more input. RPS "will provide" a GUL upon request, by snail mail or electronically. The question I have is how an open source provider might prefer to make that request with its associated promise about PAS Functions -- once and for all, or from time to time, etc. This question could be sorted out on a per-license basis, but I think consistency would be preferable. For (2) I'd like each Ma
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, You observed: > > Normal IPR disclosure process is to alert the IETF community via > > the IETF > > website that a patent has been filed. I mistakenly thought that > > adding the > > boilerplate IPR statement at the top of the ID was sufficient to > > say what > > needed to be said. However, I don't think IETF requires the > > disclosure of > > an unpublished patent application. > > I believe that is required even for patent applications. RFC 3979 > talks about patent applications in several places. You're right, please let me correct myself again here. My use of the term "disclosure" was sloppy. Here's what I was told by IESG: > >The IESG has been informed by Mark Brown that he had knowledge of the > >September 2005 patent application filed by his employer at the time > >he submitted draft-housley-tls-authz-extns. Accordingly, he was > >obligated to disclose the existence of this patent application upon > >making this submission. Making a required IPR disclosure after a > >draft is approved does not meet the requirement to promptly make the > >disclosure. According to section 7 of RFC 3979 failure to make a > >required disclosure is a failure of process. It should be noted that > >the above disclosure obligations apply to unpublished patent > >applications. When a patent application that is required to be > >disclosed is unpublished, the discloser must 'indicate that the claim > >is based on unpublished patent applications', but is not required to > >list the application number (see RFC 3978 Section 6.4.1). The content of the IETF-required IPR disclosure is this: 1. (YES) "the discloser must 'indicate that the claim is based on unpublished patent applications'" Not these: 2. (NO) "list the application number (see RFC 3978 Section 6.4.1)." 3. (NO) otherwise publish to the IETF the pending patent claims or description of the invention disclosed in any unpublished patent application(s) What I meant to say in my earlier email is that I don't think IETF requires disclosure of the body of the patent application, it's claims, etc. as in (3). I recognize that IETF does require the required IPR disclosure made via http://www.ietf.org/ipr-instructions as described in (1). This probably isn't news to any of you, but I wanted to correct my sloppy use of the term "disclosure". Thanks, mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Harald, I want to apologize again for screwing up the IPR disclosure process. Normal IPR disclosure process is to alert the IETF community via the IETF website that a patent has been filed. I mistakenly thought that adding the boilerplate IPR statement at the top of the ID was sufficient to say what needed to be said. However, I don't think IETF requires the disclosure of an unpublished patent application. I finally made my disclosure on the IETF website (what I mistakenly thought was a second disclosure) after my patent got published. And, in all honesty, even this disclosure got delayed because I sought advice. Please note that the filing's publication, the delay, and the IPR disclosure all happened after the last IETF approval for the ID. The right thing to do is to use the IETF website the very day your file your first ID, and not hope that the verbiage atop the ID will somehow disclose that IPR filings are in progress. As a result of my mistakes, the IETF withdrew approval of the ID and explained the process to me. That's fair. But please keep in mind that even for important things, it's easy to make mistakes your first time through a process. --mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
Simon, I filed for patent (Jan and Sep 2005) and later promoted TLS authz (Feb 2006) in good faith. It is possible that the patent claims can be read more broadly than I expected, but that's a fairly detailed and unresolved legal question. I am working diligently to -- let me speak carefully -- explore if and how I can make a royalty free license grant to ensure that promoting TLS authz continues to be an act in good faith, while still protecting a way for my company to make money on its IPR. I have experienced some surprises when mixing law and Internet standards. To try to avoid surprises, I have hired IPR attorneys at two different firms to review my draft which proposes a royalty-free license grant. I expect any resulting license will be conditioned upon IETF acceptance of TLS authz as a standard. I hope to have concluded these services next week. I think IPR questions are complicated in part because for some questions only a lawsuit can answer the question -- but we should all want to stay clear of these kinds of lawsuits! So answers seem to me to be in short supply. I want to craft the proposed license to make this situation a little clearer than that, but doing so often involves taking risks of giving away a huge loophole. So I'm working to get good legal advice. In short, I am working to create a royalty-free license grant -- hopefully I can disclose it next week. With some luck, it will clarify the situation. Best regards, mark > -Original Message- > From: Simon Josefsson [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 29, 2007 10:12 AM > To: Sam Hartman > Cc: ietf@ietf.org; iesg@ietf.org; [EMAIL PROTECTED] > Subject: Re: Withdrawal of Approval and Second Last Call: draft-housley- > tls-authz-extns > > Sam Hartman <[EMAIL PROTECTED]> writes: > > >> "Simon" == Simon Josefsson <[EMAIL PROTECTED]> writes: > > > > Simon> I don't care strongly about the standards track status. > > Simon> However, speaking as implementer of the protocol: If the > > Simon> document ends up as informational or experimental, I > > Simon> request that we make an exception and allow the protocol to > > Simon> use the already allocated IANA protocol constants. That > > Simon> will avoid interoperability problems. I know the numbers > > Simon> are allocated from the pool of numbers reserved for > > Simon> standards track documents. There is no indication that we > > Simon> are running out of numbers in that registry. Thus, given > > Simon> the recall, I think the IETF should be flexible and not > > Simon> re-assign the IANA allocated numbers at this point just > > Simon> because of procedural reasons. > > > > Would you support publication on the standards track given the IPR > > situation as someone who has implemented? > > If the patent concern is valid and covers TLS libraries or other > applications, no. > > However, as far as I am aware of the public information that is > available, the situation appears to be that we don't know whether > these patents apply and to what extent. I don't know whether the > patents were filed in good or bad faith. More information from the > patent holders may help here. > > If it is possible to implement the protocol without violating the > patents, I would support publication. I've seen some claims that this > may be possible. I have no interest in reading these patents myself, > but my position would be influenced if someone knowledgeable reads the > patents. > > Given the amount of patents out there, it would be unreasonable for us > to move everything to informational just because someone finds > something that may be relevant to a piece of work. > > The community needs to evaluate patent claims, and preferably reach > conservative agreement (rough consensus is not good enough) on whether > we should care about a particular patent or not. Input to that > community evaluation process may be documentation of legal actions > taken by a patent owner. Sometimes that may happen only after a > document has been published. > > I would support down-grading standards track documents that later turn > out to be patent-infected to informational. Doing so would avoid > sending a message that the IETF supports patented technology, when the > IETF community didn't know about the patents at publication time. For > credibility of the process, I believe it is important that these > decisions are only made based on publicly available information. > > /Simon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
