Re: [HOKEY] EMSK key hierarchy and the DSRK
I agree with removing DSRK. Let me explain one of Dan's points in a different way. The domain in DSRK is defined for key management domain for HOKEY, and ERX is the only usage defined for HOKEY. It would be very hard to justify deriving child keys from DSRK for usages other than HOKEY, given this situation. Yoshihiro Ohba On Wed, Mar 19, 2008 at 09:45:47AM -0700, Dan Harkins wrote: > > Hello, > > My apologies for being obtuse. This Mother of All Root Keys I've been > describing is what the EMSK Key Hierarchy calls the DSRK. > > The "HOKEY key" that the ERP/ERX draft uses can be derived in one of > two ways: > > EMSK > | > USRK<-- the "HOKEY key", aka rRK > > or like this: > > EMSK > | > DSRK<--- the MOARK > | >DSUSRK <-- the "HOKEY key", aka rRK > > This latter derivation is the one that will be used in practice, I believe. > > This DSRK is not properly defined and cannot be properly scoped. It > really has nothing to do with "Handover Keying" which is what HOKEY is > supposed to be working on. I believe the DSRK is problematic and the > ability to derive a DSRK should be removed from the ESMK key hierarchy > draft and the corresponding change be made to the ERP/ERX draft to remove > reference to using a DSRK to derive HOKEY keys. > > This change would also simplify the key hierarchy and remove a > "you can do it this way, or you can do it that way" option which > experience has shown is a really bad idea. > > regards, > > Dan. > > On Tue, March 18, 2008 6:22 pm, Dan Harkins wrote: > > > > Hi Avi, > > > > On Tue, March 18, 2008 3:13 pm, Avi Lior wrote: > > [snip] > >> I suggest we discuss the issues with deriving keys from EMSK so that > >> people can make informed decisions. Lets keep the FUD factor low. > > > > Good idea. Can we start with the Mother Of All Root Keys (MOARK) that > > is derived from the EMSK? This seems like a particularly un-scope-able > > and undefined key. It is not needed for Handover Keying; all HOKEY needed > > to do was define a HOKEY-specific key from the EMSK but it didn't, it > > defined a MOARK, and then a HOKEY-specific key is being derived from the > > MOARK. > > > > Since the MOARK is really the only key being derived from the EMSK > > I guess this makes for a nicely constrained discussion. > > > > Dan. > > > > > > > > ___ > > IETF mailing list > > IETF@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > > > ___ > HOKEY mailing list > [EMAIL PROTECTED] > https://www.ietf.org/mailman/listinfo/hokey > ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Possible RFC 3683 PR-action
LB: Randy has responded quite publicly. I think his position is quite clear. So, the next step is up to you. Russ At 08:38 PM 3/20/2008, LB wrote: >Dear Sir, >Like other members of the multilinguistic working list to which I >belong, since 2002 I received a copy of the mails exchanged between >JFC Morfin and your organization, on IDNs then langtags. And we have >often discussed them. I do not thus ignore big matter of this subject > >As JFC Morfin got everything we wanted except again: >(1) that the WG-IDNABIS quickly demonstrates the merits of IDNA or >finds a better solution. >(2) that the RFC 4646 is respected by the IESG what also calls for the >RFC 4646bis underway. >I proposed to replace him as an IETF watcher, given the importance of >his current work. > >In two months, I sent a half-dozen of messages and received courteous >answers. Of course I expected a possible ostracism. I was prepared to >respond with kind understanding. This was the case with Brian >Carpenter. He accused me of being JFC Morfin in an humorous but a way >a little hurtful. We exchanged and he had the courtesy to apologize >willingly and and to inform the IESG about it. > >I would have done the same with Randy Preshun if contacted me, even >impolitely, even after having ignored my question about a significant >breakthrough for us he implied, even after that he probably pushed a >"trap" by misrepresenting our position and that of ISO. Instead, he >dashes into a guerilla of racist censorship against me: it is because >of the MLTF ideas that he accuses me of not being me. > >2008/3/20, Randy Presuhn <[EMAIL PROTECTED]>: > > Hi - > > > > There have been expressions of support, and no objections on this list, > > to the proposed metric (and one off-list objection by JFC Morfin) for > > identifying possible sock-puppets of those whose posting privileges > > have been revoked pursuant to RFC 3683. So, we're using it. > > > > We engaged the procedure with three independent working group > participants. > > All three identified the same email address, which was also > identified by the > > responsible area director and both co-chairs. Consequently, > future postings > > from [EMAIL PROTECTED] will not be delivered, since we believe > this address > > is a sock-puppet for JFC Morfin. > > > > Randy > > ltru co-chair > >You will understand that I have reached an age where I am not >impressed anymore and that I have time for a good cause: >-- or Randy Preshun apologizes and it stays there. >-- or he has suspended my rights without warning and is preparing for >a PR action against me without any reason. He does it with the support >of our two direct commercial competitors in his WG. Under these >conditions you will understand that I am not to be giving anything >that enables them to validate a practice of arbitrary exclusion of the >IETF. Today I, whom tomorrow? >-- >LB ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom process realities of "confidentiality"
Wrenching this thread back to match the subject line . Having just gone through the nomcom process as a new addition to the IAB, I just wanted to add my two cents In the past I've volunteered for the nomcom lottery but was never selected, so I can't speak with authority about any previous nomcoms, but regarding THIS nomcom just past, from everything visible to me, the nomcom members took their responsibilities EXTREMELY seriously and professionally, and at no point did I ever feel like I had to worry about anything discussed between me and nomcom, either orally or in writing, being improperly disclosed. This included not only information provided by me about myself, but also comments I provided to nomcom regarding other nominees for the IESG and the IAB. Likewise, I remain completely ignorant of what other people may have said about me, and I prefer it that way. :-) Going forward, several people have proposed that the next nomcom and the confirming bodies agree at the beginning of the process as to what information will be needed for confirmation, and it should then be made explicitly clear to nominees as to what information will be used by which bodies. I highly support this proposal. Cheers, Andy ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Possible RFC 3683 PR-action
Hi - My co-chair Martin Duerst and I, and the three independent ltru working group participants we asked (as well as some we didn't ask), are convinced that "LB" is a sock-puppet for JFC Morfin. In consultation with Chris Newman, the responsible area director, we set the "moderated" bit for that subscriber address on the working group mailing list. If "LB" believes we have acted inappropriately, "LB" is free to follow the appeal process described in section 6.5 of RFC 2026. However, the vocabulary, style, content, and peculiar world-view of this latest missive leave me more convinced than ever that "LB" is indeed JFC Morphin, and that under the terms of RFC 3683 we are well justified in suspending the posting privileges for that address. Randy ltru co-chair > From: "LB" <[EMAIL PROTECTED]> > To: "russ Housley" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; > Sent: Thursday, March 20, 2008 4:38 PM > Subject: Re: [Ltru] Possible RFC 3683 PR-action > > Dear Sir, > Like other members of the multilinguistic working list to which I > belong, since 2002 I received a copy of the mails exchanged between > JFC Morfin and your organization, on IDNs then langtags. And we have > often discussed them. I do not thus ignore big matter of this subject > > As JFC Morfin got everything we wanted except again: > (1) that the WG-IDNABIS quickly demonstrates the merits of IDNA or > finds a better solution. > (2) that the RFC 4646 is respected by the IESG what also calls for the > RFC 4646bis underway. > I proposed to replace him as an IETF watcher, given the importance of > his current work. > > In two months, I sent a half-dozen of messages and received courteous > answers. Of course I expected a possible ostracism. I was prepared to > respond with kind understanding. This was the case with Brian > Carpenter. He accused me of being JFC Morfin in an humorous but a way > a little hurtful. We exchanged and he had the courtesy to apologize > willingly and and to inform the IESG about it. > > I would have done the same with Randy Preshun if contacted me, even > impolitely, even after having ignored my question about a significant > breakthrough for us he implied, even after that he probably pushed a > "trap" by misrepresenting our position and that of ISO. Instead, he > dashes into a guerilla of racist censorship against me: it is because > of the MLTF ideas that he accuses me of not being me. > > 2008/3/20, Randy Presuhn <[EMAIL PROTECTED]>: > > Hi - > > > > There have been expressions of support, and no objections on this list, > > to the proposed metric (and one off-list objection by JFC Morfin) for > > identifying possible sock-puppets of those whose posting privileges > > have been revoked pursuant to RFC 3683. So, we're using it. > > > > We engaged the procedure with three independent working group participants. > > All three identified the same email address, which was also identified by > > the > > responsible area director and both co-chairs. Consequently, future > > postings > > from [EMAIL PROTECTED] will not be delivered, since we believe this address > > is a sock-puppet for JFC Morfin. > > > > Randy > > ltru co-chair > > You will understand that I have reached an age where I am not > impressed anymore and that I have time for a good cause: > -- or Randy Preshun apologizes and it stays there. > -- or he has suspended my rights without warning and is preparing for > a PR action against me without any reason. He does it with the support > of our two direct commercial competitors in his WG. Under these > conditions you will understand that I am not to be giving anything > that enables them to validate a practice of arbitrary exclusion of the > IETF. Today I, whom tomorrow? > -- > LB > ___ > IETF mailing list > IETF@ietf.org > https://www.ietf.org/mailman/listinfo/ietf ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom process realities of "confidentiality"
> Nomcom is a group of people randomly selected from among a set > of folks > whose only qualifications are that they want to be on nomcom and > they like > traveling to meetings. well, in the planning meeting, i think i suggested that only people who didn't want to be on the nomcom should be eligible, but folks seemed to think this would constitute cruel and unusual punishment. the sad fact is that in the absence of rigorous membership qualifications, identifying folks who have been able to attend recent meetings is the only objective criteria we could find. if we could have switched from meeting attendance to rfc authorship, but then the environmentalists would be upset because there would be 50 or so "authors" on each rfc, thereby resulting in a larger carbon footprint for ietf activities (printing, bandwidth usage, etc.) /mtr ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
