Re: Proposed IETF Meeting Calendar 2018 - 2022
James Polk writes: > IETF 106 seems a bit late in November. Are we boxed in by other SDO > meetings, or is this by our own choice? Keep in mind that Thanksgiving isn't until November 28 in 2019. There is certainly history of IETF being held the week before Thanksgiving. > James [snip] >>2019 >>IETF 10424 - 29 March 2019 >>IETF 10521 - 26 July 2019 >>IETF 10617 - 22 November 2019 -derek -- Derek Atkins 617-623-3745 de...@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
Re: Blue Sheet Change Proposal
Harald Alvestrand <[EMAIL PROTECTED]> writes: > Diving straight into armchairing myself, I'll just note that under EU > data privacy laws, it's illegal to collect personal info for which you > have no legitimate purpose - so if we never use those emails for > anything, we shouldn't collect them. I've used them. One time when I chaired a BOF I collected the email addresses to personally ask if they wanted to be involved in the mailing list. (It was done this way because the list was not set up prior to the meeting). So, having email addresses was very important to inform everyone in the room of the list address. Maybe this is considered SPAM, but I don't think so. -derek -- Derek Atkins 617-623-3745 [EMAIL PROTECTED] www.ihtfp.com Computer and Internet Security Consultant ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Lets be careful with those XML submissions to the RFC Editor
Paul Hoffman <[EMAIL PROTECTED]> writes: > At 11:58 PM +0200 11/25/07, Jari Arkko wrote: >>Paul, >> >>> >>> They still should (strongly) consider checking the validity of the XML >>> by comparing it to what the IESG approved. >> >>Yes, and they do compare to what IESG approved. Substantial changes are >>brought to the AD's approval. This is what caused us to find the problem >>in this case. > > I'm confused. Why should the RFC Editor accept XML with any > substantial changes? That's inherently prone to error. They should > start with what was approved. The problem is that it's the TXT that's approved, not the XML.. This whole thread is about making sure that the XML received by the RFC Editor matches the Text that was approved by the IESG. Starting with what was approved necessarily means ignoring the XML and starting with the TXT, unless they validate that the XML generates the approved TXT. -derek -- Derek Atkins 617-623-3745 [EMAIL PROTECTED] www.ihtfp.com Computer and Internet Security Consultant ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Global PKI on DNS?
David Conrad <[EMAIL PROTECTED]> writes: > Why do you think the roots and TLDs would get millions of TCP queries for > their certs? Why would anyone want to get the certs of the roots or tlds? Just to play devil's advocate, if a resolver was going to track a signature chain all the way back up, it's going to have to request the KEY/SIG records for all the parent domains all the way back to the root. In other words, resolvers all over the world are going to make requests to verify the KEY of, e.g. .COM. So, yes, there may be millions of requests to the root servers for KEY/SIG records in order to verify the leaf KEY/SIG record chains. Hopefully caching will help, but the traffic for "COM. IN SIG" is going to be a fairly popular DNSSec request, IMHO. -derek -- Derek Atkins Computer and Internet Security Consultant [EMAIL PROTECTED] www.ihtfp.com
Kerberized Key Management Protocol BOF, Wed, Aug 2, 0900-1130
The Kerberized Key Management Protocol (KKMP) BOF will be meeting in South Room 10 from 0900-1130 tomorrow, Wednesday, August 2. A short description of KKMP follows. -derek KKMP is trying to create a standards track protocol to facilitate centralized key exchange in an application independent fashion. Participating systems will use the Kerberos architecture as defined in RFC 1510 for key management and the KKMP protocol between applications. The goal of KKMP group is to produce a streamlined, fast, easily managed, and cryptographically sound protocol that is flexible enough to be able to be extended for many applications. The focus of the initial protocol will be keying IPsec security associations as defined in RFC 2401. The working group may consider means to key other protocols in the future, but the initial goal of the KKMP working group is specifically targeted at producing a streamlined and efficient keying mechanism for IPsec. The working group will not be involved with, nor should it require changes to either IPsec (RFC 2401), or Kerberos (RFC 1510). -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL N1NWH [EMAIL PROTECTED]PGP key available
