From Sandra.Murphy@cobham.com Tue Dec 1 10:46:31 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0238E28C162 for ; Tue, 1 Dec 2009 10:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkMzcjEJTCLQ for ; Tue, 1 Dec 2009 10:46:29 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 48A1828C154 for ; Tue, 1 Dec 2009 10:46:29 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nB1IkKHF003596 for ; Tue, 1 Dec 2009 12:46:20 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nB1IkI3G020593 for ; Tue, 1 Dec 2009 12:46:20 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Dec 2009 13:46:16 -0500 Date: Tue, 1 Dec 2009 13:46:14 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="507234791-10924-1259693174=:6176" X-OriginalArrivalTime: 01 Dec 2009 18:46:17.0034 (UTC) FILETIME=[90ACD2A0:01CA72B6] Subject: [sidr] IETF 76 minutes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2009 18:46:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --507234791-10924-1259693174=:6176 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Below you will find the minutes from our meeting at IETF 76 in Hiroshima. My apologies to Paul Hoffman, who took the minutes and sent them to me promptly. My fault for the delay. Please send any comments, corrections or additions to the list. --Sandy --507234791-10924-1259693174=:6176 Content-Type: TEXT/plain; charset=X-UNKNOWN; name=sidr.IETF76.minutes.txt Content-Transfer-Encoding: BASE64 Content-Description: Content-Disposition: attachment; filename=sidr.IETF76.minutes.txt DQpTSURSDQpNb25kYXkgbW9ybmluZyAyMDA5LTEwLTA5DQpTYW5keSBNdXJw aHkgYW5kIEdvZWZmIEh1c3Rvbg0KDQpNaW51dGVzIGJ5IFBhdWwgSG9mZm1h bg0KTWF0ZXJpYWwgZnJvbSB0aGUgc2xpZGVzIGlzIG5vdCByZXByb2R1Y2Vk IGhlcmUNCg0KQmx1ZSBzaGVldHMgYW5kIGdyb292eSBSRklEIHRoaW5nIHdl cmUgcGFzc2VkIGFyb3VuZA0KDQpBZ2VuZGEgYWRkaXRpb25zDQoJU3JpcmFt IGhhcyBzb21lIGFkZGl0aW9uYWwgdXNlIGNhc2VzLCBpZiB3ZSBoYXZlIHRp bWUNCg0KV0cgTGFzdCBDYWxsIGRlYWRsaW5lIGlzIG5leHQgTW9uZGF5DQoJ UGxlYXNlIGNvbW1lbnQgb24gdGhlIGxpc3QsIHdlIG5lZWQgbW9yZSBmZWVs aW5nIGFib3V0IGNvbnNlbnN1cw0KDQpDdXJyZW50IGRyYWZ0cyB3ZXJlIHBy ZXNlbnRlZA0KDQpSUEtJIEFyY2hpdGVjdHVyZSAtIGRyYWZ0LWlldGYtc2lk ci1hcmNoLTA5LnR4dA0KCU1hdHQgTGVwaW5za2kNCglEaXNjdXNzaW9uIGFi b3V0IHJlY29tbWVuZGF0aW9uIGFib3V0IHF1ZXJ5IGZyZXF1ZW5jeQ0KCQlQ cm9iYWJseSBkb2Vzbid0IGJlbG9uZyBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRv Y3VtZW50DQoJVHVybnMgb3V0IHRvIGJlIGNvbnRlbnRpb3VzDQoJUG9zc2li bGUgb3BlcmF0aW9uYWwgY29uc2lkZXJhdGlvbnMgZG9jdW1lbnQNCglSYW5k eSBCdXNoOiBNVFRSIHdhcyBjb3JyZWN0IGluIHRoZSBicmVha3VwIG9mIGNo YWlucw0KCUluIFdHIExDDQoNCkNQIC0gZHJhZnQtaWV0Zi1zaWRyLWNwLTA3 LnR4dA0KCVN0ZXBoZW4gS2VudA0KCVtbWyBTY3JpYmUgbm90ZTogTWF5YmUg YWxzbyBjb3ZlcmVkDQoJCUNQUy1JUiAtIGRyYWZ0LWlldGYtc2lkci1jcHMt aXJzLTA0LnR4dA0KCQlDUFMtSVNQIC0gZHJhZnQtaWV0Zi1zaWRyLWNwcy1p c3AtMDMudHh0IGJ1dCBjYW4ndCB0ZWxsIF1dXQ0KCUhhdmUgYSBidW5jaCBv ZiBjaGFuZ2VzIHRvIGJlIG1hZGUNCgkJRm9yZ290IHRvIG1ha2Ugc29tZSBj aGFuZ2VzIHRoYXQgd2VyZSBhZ3JlZWQgdG8NCglXaWxsIHNheSAiQkNQIiBp bnN0ZWFkIG9mICJJbmZvcm1hdGlvbmFsIg0KCUluIFdHIExDLCBidXQga25v d3MgdGhhdCB0aGVyZSB3aWxsIGJlIGFub3RoZXIgZHJhZnQgd2l0aCB0aGUg a25vd24gaXNzdWVzDQoNClJPQSBGb3JtYXQgLSBkcmFmdC1pZXRmLXNpZHIt cm9hLWZvcm1hdC0wNi50eHQNCglNYXR0IExlcGluc2tpDQoJTm93IHBvaW50 cyB0byB0aGUgYWxnb3JpdGhtcyBkb2N1bWVudA0KCVJvYiBBdXN0ZWluOiB0 aGUgb3JkZXIgb2YgdGhlIGNoZWNraW5nIHNob3VsZCBub3QgYmUgbWFuZGF0 ZWQNCgkJTWF5YmUgc3VnZ2VzdCBhbiBvcmRlcg0KDQpNYW5pZmVzdHMgLSBk cmFmdC1pZXRmLXNpZHItcnBraS1tYW5pZmVzdHMtMDUudHh0DQoJTWF0dCBM ZXBpbnNraQ0KCUdhdmUgb3ZlcnZpZXcgb2Ygd2h5IHdlIHdhbnQgbWFuaWZl c3RzDQoJV2FudHMgbW9yZSByZXZpZXcNCglBdXRob3JzIGtub3cgb2Ygbm8g b3V0c3RhbmRpbmcgaXNzdWVzDQoNCkNlcnRpZmljYXRlIFByb2ZpbGUgLSBk cmFmdC1pZXRmLXNpZHItcmVzLWNlcnRzLTE3LnR4dA0KCUdlb3JnZSBNaWNo YWVsc29uDQoJQ1JMIHJlYXNvbiBjb2RlcyBoYWQgbGl0dGxlIGludGVyZXN0 IGZyb20gdGhlIFdHDQoJRG8gd2UgaGF2ZSB0byB0aGluayBhYm91dCBhbGdv cml0aG0gdHJhbnNpdGlvbj8NCglSb2I6IGFsZ29yaXRobSB0cmFuc2l0aW9u IGp1c3QgbG9va3MgbGlrZSBrZXkgcm9sbA0KCVN0ZXZlIEtlbnQ6IHdoYXQg Um9iIHNhaWQNCg0KUmVwb3NpdG9yeSBTdHJ1Y3R1cmUgLSBkcmFmdC1pZXRm LXNpZHItcmVwb3Mtc3RydWN0LTAzLnR4dA0KCUdlb3JnZSBNaWNoYWVsc29u DQoJU3VnZ2VzdGlvbnMsIG5vdCBwcmVzY3JpcHRpdmUgc3RhdGVtZW50DQoN ClJPQSBWYWxpZGF0aW9uIC0gZHJhZnQtaWV0Zi1zaWRyLXJvYS12YWxpZGF0 aW9uLTAzLnR4dA0KCUdlb3JnZSBNaWNoYWVsc29uDQoJTm8gcmVjb21tZW5k YXRpb25zIGFib3V0IGhvdyBpdCBzaG91bGQgYmUgZG9uZSBpbiBCR1ANCglT YW5keSBNdXJwaHk6IElzIHRoYXQgb25lIHNlbnRlbmNlIGEgcmVjb21tZW5k YXRpb24/DQoJCUdlb3JnZTogd2lsbCByZXZpZXcgdGhhdCB3b3JkaW5nDQoJ U2FuZHk6IGRpZG4ndCBwdXQgdGhpcyB0aHJvdWdoIFdHIExDIHlldCwgb24g cHVycG9zZQ0KCQlMb3RzIG9mIGRpZmZlcmVudCBxdWVzdGlvbnMsIGluY2x1 ZGluZyBJUFINCgkJU2hvdWxkIHRoZSB2YWxpZGF0aW9uIHNjaGVtZSBiZSB3 aXRoIGFuIGltcGxlbWVudGF0aW9uPw0KCUpvaG4gU2N1ZGRlcjogVGhpcyBp cyBpbmZvcm1hdGlvbmFsDQoJCVRoZXJlIGlzIGEgbmVlZCBmb3IgYSBzdGFu ZGFyZHMgdHJhY2sgZG9jdW1lbnQgdGVsbGluZyBCR1AgaW1wbGVtZW50ZXJz IHdoYXQgdG8gZG8NCgkJSWYgdGhpcyB3YXMgdGhlIG9ubHkgZHJhZnQsIHRo YXQgaXMgbm90IGEgZ29vZCB0aGluZyBiZWNhdXNlIGl0IGlzIG5vdCBoZWxw ZnVsIHRvIHRoZSBpbXBsZW1lbnRlcg0KCQlHZW9yZ2U6IFNpbWlsYXIgdG8g cHJldmlvdXMgcXVlc3Rpb24gb24gUEtJWA0KCQkJRG9lc24ndCBmZWVsIGNv bWZvcnRhYmxlIHRlbGxpbmcgcGVvcGxlIHdoYXQgd2lsbCB3b3JrDQoJCQlB Z3JlZXMgdGhhdCBzb21ldGhpbmcgbm9ybWF0aXZlIGlzIG5lZWRlZA0KCQlK b2huOiBEbyB5b3UgaGF2ZSBjb25jZXJuIGFib3V0IHRoZSB0d28gZHJhZnRz IGhhdmluZyBhIGxvdCBvZiBvdmVybGFwPw0KCQlHZW9yZ2U6IEhhcyBpc3N1 ZXMgdGhhdCBuZWVkcyB0byBiZSB0aG91Z2h0IGFib3V0DQoJUnVzcyBXaGl0 ZTogTmVlZCB0byBiZSBjYXJlZnVsIHdpdGggYW55IHByZXNlY3JpcHRpdmUg ZG9jdW1lbnQNCgkJQ3VzdG9tZXJzIHdhbnQgcG9saWN5IHRvIGJlIGxlZnQg b24gdGhlIHJvdXRlcg0KCQlXZSBuZWVkIHRvIGJlIHN1cmUgdGhhdCB3ZSB1 bmRlcnN0YW5kIHdoZXJlIHRoZSBsaW5lIGJldHdlZW4gaXMgZHJhd24NCglS /GRpZ2VyIFZvbGs6IE9iamVjdHMgdG8gdGhlIGNsYWltIHRoYXQgbm9uZSBv ZiB0aGUgY3VzdG9tZXJzIHdhbnQgYW4gZXh0ZXJuYWwgc2VydmVyDQoJR2Vv ZmY6IENhbiBhIHN0YW5kYXJkcyB0cmFjayBwb2ludCB0byBhbiBpbmZvcm1h dGlvbmFsIGRvYz8NCglSdXNzIEhvdXNsZXk6IFllcywgd2l0aCBhIGZldyBl eHRyYSBzdGVwcw0KCVJ1c3MgV2hpdGU6IExvdHMgb2YgY29uY2VybiB0aGF0 IG9mZi1ib3hlcyB3b3VsZCB3b3VsZCBkZWNpZGUgdGhlIHBvbGljDQoJQ2hy aXMgTGlsamVuc3Ryb2xwZTogT2ZmLWJveCBwcm9jZXNzIHNob3VsZCBiZSBw cm92aWRpbmcgZnVydGhlciBpbnB1dCB0byBCR1AgYmVzdCBwYXRoDQoJR2Vv cmdlOiBTZWVzIHJlYXNvbiB0byBoYXZlIGRpZmZlcmVudGlhdGlvbiBhbmQg dGhlcmVmb3JlIG1vcmUgdGhhbiBvbmUgZG9jdW1lbnRzDQoNClRBIC0gZHJh ZnQtaWV0Zi1zaWRyLXRhLTAyLnR4dA0KCUdlb3JnZSBNaWNoYWVsc29uDQoJ Tm90IG11Y2ggbGVmdCB0byBkbw0KDQpQcm92aXNpb25pbmcgUHJvdG9jb2wg LSBkcmFmdC1pZXRmLXNpZHItcmVzY2VydHMtcHJvdmlzaW9uaW5nLTA1LnR4 dA0KCUJ5cm9uIEVsbGFjb3R0DQoJSW4gV0cgTEMsIGNvdXBsZSBvZiBpZGVu dGlmaWVkIGlzc3Vlcw0KCVJvYjogSFRUUFMgZG9lcyBub3QgcHJvdmlkZSBy ZXBsYXkgcHJvdGVjdGlvbg0KCQlNaWdodCBuZWVkIHRpbWVzdGFtcHMNCgkJ VGhpbmtzIHRoZXJlIGlzIGF0IG9uZSByZWFsIHJlcGxheSBhdHRhY2sNCgkJ CUlmIHRoZSBhdHRhY2tlciBjYW4gY2FwdHVyZSB0aGUgUEtDUzEwIGF0dGFj aywgbWlnaHQgYmUgYWJsZSB0byBkbyBzb21ldGhpbmcgd2l0aCBpdA0KCQkJ TWlnaHQgYmUgcGxhdXNpYmxlIGJhc2VkIG9uIHdoZXRoZXIgdGhlIGtleXMg YXJlIGtlcHQgb25saW5lIG9yIG9mZmxpbmUNCgkJCVRoZSBjb25zZXF1ZW5j ZSBpcyBhIGtleSBjb21wcm9taXNlIG9mIHRoZWlyIHByaXZhdGUga2V5cyBm b3IgdGhlIFJQS0kNCgkJCUNhbiBhc2sgZm9yIGEgcmVpc3N1ZWQga2V5DQoJ CVJvYmVydCBLaXN0ZWxla2k6IElmIHRoZSBwYXJlbnQgcmVtZW1iZXJzIHRo YXQgdGhlIGtleSBoYXMgYmVlbiByZW92a2VkLCBpdCBjYW4gYmUgcHJldmVu dGVkIGluIHRoZSBwcm90b2NvbA0KCQlOb3QgYSB1c2Ugb2YgYW4gb2xkIGNl cnRpZmljYXRlLCBpdCdzIGdldHRpbmcgYSBuZXcgY2VydA0KCQlTdGV2ZSBL ZW50OiBXaHkgd291bGQgb25lIHNldCBvZiBrZXkgbWF0ZXJpYWwgYmUgcHJv dGVjdGVkIHRoYW4gYW5vdGhlcg0KCQkJTGV0J3MgYmUgcHJlY2lzZSBpbiB3 aGF0IGlzIGJlaW5nIG9mZmVyZWQNCgkJVExTIGlzIGhpZGluZyB0aGUgZGV0 YWlscw0KCQlXaWxsIHByb3ZpZGUgcGljdHVyZXMNCg0KUlBLSSBBbGdvcml0 aG1zIC0gZHJhZnQtaWV0Zi1zaWRyLXJwa2ktYWxncy0wMC50eHQNCglHZW9m ZiBIdXN0b24NCglCaWdnZXN0IHF1ZXN0aW9uIGlzIGhhbmRsaW5nIG11bHRp cGxlIGFsZ29yaXRobXMgYXQgdGhlIHNhbWUgdGltZQ0KCVRocmVlIGNob2lj ZXMNCglOb3QgdGhlIHNhbWUgYXMga2V5IHJvbGxvdmVyDQoJCVJvbGxvdmVy IG92ZXJ3cml0ZXMsIGlzIG5vdCBwYXJhbGxlbA0KCQlBbGdvcml0aG0gY2hh bmdlIG5lZWRzIGJvdGggYmVpbmcgdmFsaWQNCglJZiB3ZSBnbyBkb3duIHRo ZSBwYXRoIG9mIHBhcmFsbGVsIGlzc3VhbmNlLCB3ZSBuZWVkIHRvIGtub3cg KmhvdyogdGhleSBnbyBwYXJhbGxlbA0KCUxpa2VzICJwdW50IiB0aGUgYmVz dA0KCVJvYjogT25seSBhZ3JlZWQgdG8gdGhlIGZpcnN0IHR3byB0aGlyZHMN CgkJRG9lc24ndCBsaWtlIG9wdGlvbiBDDQoJVGltIFBvbGs6IFRyYW5zaXRp b24gZnJvbSBvbmUgYWxnb2lyaHRtIG1lYW5zIGFsbCB0aGUgcmVseWluZyBw YXJ0aWVzIGNhbiBkbyB0aGUgbmV3IG9uZQ0KCQlKdXN0IGRvZXNuJ3Qgd29y aw0KCQlOZWVkIGEgcGVyaW9kIG9mIHRpbWUgd2hlcmUgYXJlIHVzaW5nIGJv dGgNCglSb2I6IFdlIGFscmVhZHkgdXNlIGhhc2hlcyBvZiBwdWJsaWMga2V5 cywgc28gdGhhdCBtYXkgc2F2ZSB1cw0KCQlXZSBjb3VsZCByZXF1aXJlIGtl eSBjaGFuZ2VzIHdoZW4gdGhlIHRyYW5zaXRpb24gaGFwcGVucw0KCUdlb3Jn ZTogQ291bGQgbWFrZSBhIHJlcXVpcmVtZW50IGZvciB0b3AtZG93bg0KCQlU aGlzIHdvdWxkIG1ha2UgdGhlIHNpemUgb2YgdGhlIHJlcG9zaXRvcnkgc21h bGxlcg0KCVBhdWwgSG9mZm1hbjogRG9uJ3QgYXNzdW1lIHRoYXQgdGhlIHRv cCB3aWxsIHdhbnQgdG8gZG91YmxlLXNpZ24ganVzdCBiZWNhdXNlIHRoZSBv bmVzIGJlbG93IGRvDQoJUm9ndWUgR2FnbGlhbm86IEFueSB0cmFuc2l0aW9u IHdpbGwgY2F1c2UgYSBsb3Qgb2YgcHJvYmxlbXMgYW5kIHF1ZXN0aW9uDQoJ CUdlb2ZmOiBUaGVyZSB3aWxsIGJlIHRyYWRlb2ZmcyByZWdhcmRsZXNzDQoJ U3RldmUgS2VudDogV2UgYXJlIHRhbGtpbmcgYWxvZ2l0aG0gdHJhbnNpdGlv bnMgdGhhdCBoYXBwZW4gYnkgYSBjaGFuZ2UgdG8gdGhlIENQDQoJCUNhbiBv bmx5IG9jY3VyIHdoZW4gdGhlIHNlY29uZCBzZXQgb2YgYWxnb3JpdGhtcyBo YXZlIGFscmVhZHkgYmVlbiBkZWZpbmVkDQoJV2lsbCB0YWtlIHRoaXMgdG8g dGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgcmV2aXNpbmcgdGhlIGRyYWZ0DQoJ CVdpbGwgdGFrZSBpdCBiYWNrIHRvIHRoZSBTZWN1cml0eSBBRHMgYW5kIFNl Y2Rpcg0KCVNhbmR5OiBTZWN1cml0eSBBRHM6IGhvdyB0byBwcm9jZWVkPw0K CQlUaW0gUG9sazogT3RoZXIgZHJhZnRzIGNhbiBiZSBtb3ZlZCBmb3J3YXJk DQoJCQlXb3VsZCBsaWtlIHRvIHNlZSBhIHNlY29uZCBhbGdvcml0aG0gc3Bl Y2lmaWVkIG5vdzsgbWF5YmUgRUNEU0ENCgkJCVdvdWxkIGFsc28gbGlrZSB0 byBzZWUgdGhlIHRyYW5zaXRpb24gZGVzY3JpYmVkDQoJCQlXYW50cyB0byBz ZWUgYXQgbGVhc3QgLTAwcyBiZWZvcmUgdGhlIGN1cnJlbnQgc3R1ZmYgY2Fu IGJlIFJGQ3MNCgkJCVdhbnRzIG1vcmUgdGhhbiBqdXN0IGEgcHJvbWlzZSB0 byBzdGFydA0KCQlBZHJpYW4gRmFycmVsOiBJcyB0aGUgbmV3IHN0dWZmIG5v cm1hdGl2ZT8NCgkJCUdlb2ZmOiBOb3RlZA0KCQlTYW5keTogSW1wbGVtZW50 YXRpb24gcmVwb3J0Pw0KCQkJQWRyaWFuOiBOb3QgcmVxdWlyZWQsIGJ1dCB3 b3VsZCBiZSBuaWNlDQoJCQlSb3NzIENhbGxvbjogV2FzIHJlcXVpcmVkIGlu IHllYXJzIHBhc3QsIGJ1dCBub3Qgbm93Lg0KCQkJCU5vdyBuZXcgc3R1ZmYg aXMgc21hbGwgZW5oYW5jZW1lbnRzDQoJCQlSb2I6IFdhbnRzIGFsZ29yaXRo bXMgZnJvbSBPcGVuU1NMDQoJCQlQYXVsOiBFQ0RTQSBpcyBpbiBPcGVuU1NM DQoNClVwZGF0ZSBvbiBVc2UgQ2FzZXMgLSBkcmFmdC1tYW5kZXJzb24tc2lk ci11c2VjYXNlcy0wMS50eHQNCglUZXJyeSBNYW5kZXJzb24NCglXYW50cyBt b3JlIHVzZSBjYXNlcz8NCglTdGV2ZSBLZW50OiBQcm9ibGVtIHdpdGggZGVm aW5pdGlvbnMNCgkJTm8gaW50cm9kdWN0aW9uIHRvIGhvdyB0aGUgdXNlIGNh c2VzIHdlcmUgY2hvc2VuDQoJCU1heWJlIGEgZGVjaXNpb24gdHJlZQ0KCURh bm55IE1jUGhlcnNvbjogQWdyZWVzIHdpdGggU3RldmUNCgkJV291bGQgbGlr ZSB0byBzZWUgYSB0YXhvbm9teQ0KCQlBdCB3aGF0IHBvaW50IHdvdWxkIHdl IGJyaW5nIHBhdGggdmFsaWRhdGlvbiBpbnRvIHNjb3BlPw0KCQlTYW5keTog U3RpbGwgdGhpbmtpbmcsIGJ1dCB3YW50cyB0byBoZWFyIGZyb20gUm91dGlu ZyBBRHMNCgkJCVJvc3M6IEZpbmlzaCBjb21wbGV4IHdvcmsgZmlyc3QNCgkJ CQlXYW50cyB0byBoZWFyIHdoZXRoZXIgdGhlcmUgaXMgY29uc2Vuc3VzIHRv IHdvcmsgb24gcGF0aCB2YWxpZGF0aW9uIGF0IGFsbA0KCVNhbSBXZWlsZXI6 IFRoYW5rcyBmb3Igcm91dGUgYW5ub3VuY2VtZW50cyB0aGF0IHNob3VsZCBu b3QgYmUgdmFsaWRhdGVkDQoJR2VvZmY6IHBsZWFzZSB2b2x1bnRlZXIgaWYg eW91IHdhbnQgdG8gc2VlIHRoaXMgYXMgYSBXRyBpdGVtPw0KDQpMb2NhbCBU QSBNYW5hZ2VtZW50DQoJU3RldmUgS2VudA0KCUJhc2ljIHJ1bGU6IHRoZSBy ZWx5aW5nIHBhcnR5IGlzIGl0cyBvd24gdHJ1c3QgYW5jaG9yDQoJV2lsbCBs YXRlciBoYXZlIGEgdG9vbCB0aGF0IGNhbiBhdXRvbWF0ZSB0aGlzDQoJCVRo YXQgdG9vbCB3aWxsIHNob3cgc29tZSBjb21wbGV4aXRpZXMNCglEYW5ueTog VHJhZGluZyBhdXRvbm9teSBmb3Igc2VjdXJpdHkNCgkJV2hhdCBhYm91dCBj b25mbGljdCByZXNvbHV0aW9uDQoJCVdoYXQgaXMgdGhlIHJlc29sdXRpb24g bW9kZWwgaWYgdGhlcmUgYXJlIGNvbmZsaWN0cz8NCgkJU3RldmU6IHlvdSB3 aWxsIGdldCB3YXJuaW5nIG1lc3NhZ2VzLCBidXQgdGhhdCdzIGl0DQoJCUNv bmNlcm4gYWJvdXQgbmFpdmUgcmVseWluZyBwYXJ0aWVzDQoJQW5kcmUgUm9i YWNoZXZza3k6IERvZXNuJ3QgdW5kZXJzdGFuZCB0aGUgdXNlIGNhc2Ugb2Yg cHJvdGVjdGluZyBhIHBhcnRpY3VsYXIgZW50aXR5DQoJCVN0ZXZlOiBXYW50 IHRvIG5vdCBiZSBmb29sZWQgaW50byBtaXNyb3V0aW5nDQoJCQlZb3UgYXJl IG5vdCBwcm90ZWN0aW5nIG90aGVyIHBhcnRpZXMgZnJvbSBtaXNyb3V0aW5n DQoJCQlJZiB5b3UgaGF2ZSBpbmZsdWVuY2UsIHlvdSBjYW4gaGF2ZSBhIGJp Z2dlciBpbmZsdWVuY2UNCglTYW5keTogQXdhcmUgdGhhdCB0aGlzIG9ubHkg Zm9yIGxvY2FsIHBvd2VyDQoJCUdpdmVzIHlvdSB0aGUgcG93ZXIgdG8gc2hv b3QgeW91cnNlbGYgaW4gdGhlIGZvb3QNCgkJSXMgd2FyeSBvZiBwZW9wbGUg dHJhZGluZyB0aGVzZSBsb2NhbCBkZWNpc2lvbnMgYXJvdW5kDQoJCURvbid0 IG1rZSBpdCB0b28gZWFzeQ0KCVL8ZGlnZXI6IEZlYXJzIHRoYXQgdGhlcmUg aXMgYSBwZXJjZXB0aW9uIHRoYXQgZXZlcnlvbmUgaGFzIHRvIGRvIHRoaXMN CgkJQ291bGQgbmVnYXRpdmVseSBhZmZlY3QgdGhvc2Ugd2hvIGtub3cgaG93 IHRvIHVzZSB0aGlzDQoJCVdvdWxkIGhhdGUgdG8gc2VlIHRoaXMgYmVjb21l IGEgZ2VuZXJhbGx5IHVzZWQgZmVhdHVyZQ0KCVJhbmR5OiBSRkMgMTkxOCBz cGFjZSBpcyB0aGUgY29tbW9uIHVzZQ0KCQlXb3VsZCBiZSBuaWNlIHRvIGhh dmUgMTkxOCBzcGFjZSBleGFtcGxlIHRoYXQgaXMgc2FmZQ0KCVJvYjogSW4g dGhlIDE5MTggc3BhY2UsIHRoZXJlIGlzIGEgY2xlYXIgcGFydGl0aW9uDQoJ CU5lZWRpbmcgYSBzZXBhcmF0ZSB0cnVzdCBhbmNob3IgdG8gZG8gaXQNCgkJ UGFyYWxsZWwgY2hhcmFjdGVyaXphdGlvbiB0byAubWlsIGxvb2tpbmcgYXQg SUFOQQ0KCQlTcG9rZSBhZ2FpbnN0IHRoaXMgaW4gU3RvY2tob2xtLCBub3cg cmV0cmFjdHMgDQoJQW5kcmU6IFN0aWxsIHVuY29tZm9ydGFibGUgYmVjYXVz ZSAiYmFyIiBjYXNlIGlzIHNvIGxpbWl0ZWQNCgkJVGhpbmtzIHRoYXQgaXQg aXMgb25seSB1c2VmdWwgaWYgeW91IGhhdmUgaW5mbHVlbmNlIG92ZXIgb3Ro ZXINCgkJU3RldmU6IERlcGVuZHMgb24gd2hhdCB5b3UgbWVhbiBieSAicHJv dGVjdGlvbiINCgkJCUl0IGlzIGFib3V0IHlvdXIgb3duIHNjb3BlDQoNClJQ S0kgT3BlcmF0b3JzIFJvdW5kdGFibGUgUmVwb3J0IGFuZCBEaXNjdXNzaW9u DQoJSm9obiBTY2huaXpsZWluDQoJSVNPQyBtZWV0aW5nIGZvciBTZWN1cmlu ZyBSb3V0aW5nIEluZm9ybWF0aW9uDQoJV2FzIG5vdCBqdXN0IGFib3V0IFJQ S0kNCglTdWNjZWVkZWQgYmVjYXVzZSBJU1BzIGRpZCBoYXJkIHdvcmsgYW5k IGV4cG9zZWQgZ29vZCBpbmZvDQoJR3JlZ29yeSBMZWJvdml0ejogUmVzb2x2 ZSB2cy4gYXNzdWFnZSBvbiB0aGUgZGlmZmVyZW5jZXMNCglUZXJyeTogQk9B IGRyYWZ0IGlzIG5vdCBkZWFkIHlldCwgYnV0IGRlcGVuZHMgb24gdGhlIGRl ZmluaXRpb24gb2YgdGhlIFJPQQ0KCURpZCBub3Qgd2FudCB0byBzdWJ2ZXJ0 IHRoZSBwdXJwb3NlIG9mIHRoaXMgV0cNCglSb2I6IFdoYXQgaXMgYSAibmVp Z2hib3IiPw0KCUphcmVkIE1hdWNoOiBTb21lIHNlcnZpY2UgcHJvdmlkZSB0 aGUgY2FwYWJpbGl0eSB0byBibGFja2hvbGUgYW4gb3JpZ2luLCBub3QganVz dCBhIGRlc3RpbmF0aW9uDQoJUmFuZHk6IFdoZW4gYW4gb3JpZ2luYXRvciBw dXRzIGEgcm91dGUgaW4sIGl0IGlzIHRvIHByb3RlY3QgdGhlbXNlbHZlcw0K CUdlb3JnZTogVGhhbmsgeW91IGZvciBob2xkaW5nIHRoaXMgKGdlbmVyYWwg YXBwbGF1c2UpDQoJV2VzIEdlb3JnZTogUm91dGVyIGJlaGF2aW9yIGluIGNv bWluZyB1cCBhbmQgY29udmVyZ2VuY2UNCg0KU29tZSBSZW1hcmtzIG9uIElT T0MgUm91bmR0YWJsZQ0KCVL8ZGlnZXIgVm9saw0KCU1vc3Qgb3BlcmF0b3Jz IHRoZXJlIGRvIHNob3cgdXAgYXQgSUVURg0KDQpSYW4gb3V0IG9mIHRpbWUN CglTYW5keSBoYWQgYSBsb25nIGxpc3Qgb2YgdGhpbmdzIHRoYXQgd2UgZGlk bid0IGdldCB0byB0YWxrIGFib3V0DQoJQWxsIG9mIHRoZW0gd2lsbCBiZSBv biB0aGUgbGlzdA0KDQo= --507234791-10924-1259693174=:6176-- From Sandra.Murphy@cobham.com Wed Dec 2 17:21:09 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04C3C3A67A2 for ; Wed, 2 Dec 2009 17:21:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTK3T8QdBlNf for ; Wed, 2 Dec 2009 17:21:07 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8F4C23A6358 for ; Wed, 2 Dec 2009 17:21:07 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nB31KwFR025915 for ; Wed, 2 Dec 2009 19:20:58 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nB31KwGU019607 for ; Wed, 2 Dec 2009 19:20:58 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 20:20:56 -0500 Date: Wed, 2 Dec 2009 20:20:52 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 Dec 2009 01:20:57.0610 (UTC) FILETIME=[DDCFB6A0:01CA73B6] Subject: [sidr] comments on draft-ietf-sidr-repos-struct-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 01:21:09 -0000 The following are not points that anyone else raised. I decided that I should raise them as working group member, NOT as working group chair. Comments on draft-ietf-sidr-repos-struct-03.txt. (1) Entry and removal from a publication point I noticed that the document frequently makes mention of manifest's listing of all objects produced by a CA. (e.g., "The manifest contains a list of the names of all objects issued by that CA or signed by the EE certificate and published in a repository publication point directory,") That is not actually true, if I understand manifests correctly. The manifest lists all objects in the publication point, which means the current, unrevoked objects. Right? I thought "current, unrevoked" ought to be added to each such mention of the manifest. This raised the question that the document says that it describes the content of the structure, but it never says when content is added or removed. I checked, and the manifest does not seem to cover this either. It says "The manifest's fileList includes the file names and hash pair for all objects associated with this CA that have been published at the CA's repository publication point." and o An authority MUST issue a new manifest in conjunction with the finalization of changes made to objects in the publication point. which pushes the question off to the description of what is in the publication point. Perhaps it would be good to add the following statement: Objects are added to the repository structure when issued or signed, and are removed when expired or revoked. IF, of course, that is true. Is it? Is it so completely obvious that it does not need to be mentioned? Note that the manifest document also says An authority MAY perform a number of object operations on a publication repository within the scope of a repository change before issuing a single manifest that covers all the operations within the scope of this change. Repository operators SHOULD implement some form of synchronization function on the repository to ensure that relying parties who are performing retrieval operations on the repository are not exposed to intermediate states during changes to the repository and the associated manifest. which seems like it deals also with the repository publication point content and would be good to include in the repository structure document. (I actually think things would still work if expired or revoked objects were left lying around in the repository, as long as the manifest checking raised no alarm for seeing them there. That's not hygenic, of course.) (2) Language regarding signing It is common to say say "the certificate signed this ". That's not actually correct, and saying it in full glory means saying things like "objects signed using the private key associated with the public key certified in the certificate". The draft goes through the tortuously precise language twice (page 4 "all objects signed by the private key part of the key pair whose public key part is the subject of this certificate" and page 8 "the EE certificate that has certified the key pair that as used to sign the object") and uses the common language many times ("or signed by the EE certificate", "all objects that are signed using a "single-use" EE certificate", "that points to the the repository publication point of the objects signed by this EE certificate", etc.) I don't think the full rigor is needed everywhere. I'd recommend putting that language near the beginning and say something like "from now on, when we will use the inaccurate but shorter statement "the certificate signed the object" to mean this signing action. (3) Language About the language in the introduction: A Resource Certificate describes an action by an Issuer that binds a list of IP address blocks and AS numbers to the Subject of a certificate, identified by the unique association of the Subject's private key with the public key contained in the Resource Certificate. Someone else remarked about this language. This is used in the rescerts document as well. I admit that I've always thought it rather convoluted and maybe not even accurate. Does a certificate embody the action of binding or does it accomplish the binding by its existence? and such philosophical pronouncements. However, I don't think the language here hinders the document to the point that it must be changed. (4) Directories and publication points The repository structure for the most part talks about "publication points", but in section 3 it starts talking about publication directories and subdirectories. Subdirectories are to be publication points for CAs that are contained in the directory. I found it difficult to maintain separation between the ideas sof a publication point and a directory - the most common case will be when the publication point is a file system directory, obviously. But does the publication point naming system have anything to do with the file system directory naming structure? Do the naming guidelines only propose a name for the last component of a hierarchical file system name, which one presumes is the directory name? Does the restriction on subdirectory contents in a publication point directory have anything to do with the required content of a publication point. (I.e., the objects listed in the manifest are all objects in the publication point, but we don't need to say "except for subdirectories" because the manifest objects are those in the abstract "publication point", not the file sytsem directory that hosts the abstract publication point. Is that anywhere near correct? Are directories and publication points synomonous? Is the "file system directory" part of the following statement exactly true? For every certificate in the PKI, there will be a corresponding repository publication point file system directory Should the following say "directory" or "publication point" That is, if the subject of certificate A has issued certificate B, then the AIA extension of certificate B points to certificate A, and the SIA extension of certificate A points to a directory containing certificate B (see Figure 1). And so forth. o Each CA publication directory in the publication repository should contain the products of this CA, including those objects signed by single-use EE certificates that have been issued by this CA. Since a directory might host products from multiple CAs, what is this trying to say? (5) Access method Sometimes the text talks about "access method" and sometimes "accessMethod". The rescerts document says "access mechanism" when it is not talking about the "accessMethod". I wasn't sure if "access method" should have been "accessMethod", and if not, then maybe "access mechanism" would remove the ambiguity. (6) Suggested naming scheme The discussion on page 6 says that CRLs and namifest both use the 4387 algorithm to dervive the name from the public key hash to a string. Obviously they can't both have the same name - is there some required suffix or extension that would distinguish them? (section 2.3 on page 7 talks about objects with a common "base name element" - probably the same term could be used here) (7) MUST and SHOULD This document uses "MUST" and "SHOULD" at times, and "must" and "should" at times. I was not sure if the lower case was meant to be upper case. Seems particularly a problem in section 4: If a CA certificate is reissued, it should not be necessary to reissue all certificates signed by the certificate being reissued. Therefore, a CA SHOULD use a persistent naming scheme for the certificates's repository publication point that is persistent across certificate reissuance events. That is, reissued certificates should use the same repository publication point as previously issued certificates having the same subject and subject public key, and should overwrite previously issued certificates within the repository publication point directory. Some of those uses of "should" seem to be normative. (8) Synchronizing repositories I wonder how the top down walk from trust anchors will work in Steve Kent's scheme in which the local trust anchor re-issues some certs to restrict authority - will the walk of the repository system still work? (I can't claim that I have full understanding of Steve Kent's proposal, so this could be really off-base.) (9) Nits I have not checked other people's nit lists to see if the following is duplicative. is "complete set" -> is a "complete set" Becuase -> Because the entity may chose to continue of use -> the entity may choose to continue the use pooint -> point Whn multiple CA's -> When multiple CA's using RSYNC [rsync][I-D.sidr-res-certs] Support -> missing the period the SIA of the associated CA or EE -> the SIA of the associated CA or EE certificate of related CA's -> of related CAs the the local repository cache will -> the local repository cache with --Sandy From Sandra.Murphy@cobham.com Wed Dec 2 17:27:22 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 062423A68DE for ; Wed, 2 Dec 2009 17:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JD-pacAsESAR for ; Wed, 2 Dec 2009 17:27:21 -0800 (PST) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 19CFB3A68AF for ; Wed, 2 Dec 2009 17:27:21 -0800 (PST) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id nB31RCEv025947 for ; Wed, 2 Dec 2009 19:27:12 -0600 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id nB31RBCM019744 for ; Wed, 2 Dec 2009 19:27:12 -0600 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.248.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Dec 2009 20:27:10 -0500 Date: Wed, 2 Dec 2009 20:27:00 -0500 (Eastern Standard Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 03 Dec 2009 01:27:11.0066 (UTC) FILETIME=[BC6893A0:01CA73B7] Subject: [sidr] comments on draft-ietf-sidr-rpki-manifests-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2009 01:27:22 -0000 In reviewing the repository structure draft, I was looking at the manifest draft to see if it answered some of my questions. I came up with the following comments on the manifests draft. This doesn't imply that I've done a full review of the manifest draft. These comments are made strictly as working group member. I do not make these comments as wg chair. Wg chair hat off. comments on draft-ietf-sidr-rpki-manifests-05.txt (1) Multiple manifests It appears to me that the algorithm described in the manifest document: 3. Check that every file at the publication point appears in one and only one manifest, and that every file listed in each manifest appears at the publication point. implies that the union of the manifests matches the union of the objects at the publication point. So if multiple CAs publish in the same publication point, one manifest might list some of the objects produced by one CA and some of the objects produced by another, as long as another manifest associated with the other CA includes all the other objects produced by that CA. I don't think that is the intent. I thought a manifest was specific to one CA and listed all that CA's objects but no other CA's objects. Other language in the document says that a manifest contains objects associated with one CA. But this is the definitive text, and it would be good to have it precise. (2) Manifests The document says that multiple CAs might publish objects in the same publication point. Manifests are supposed to list all objects produced by one CA. If there is just one CA publishing in a publication point, that's easy - retrieve all files from that publication point and compare to the manifest. If there are several CAs that publish to one publication point, what is the algorithm for the manifest to be checked? I'd guess: download all objects from publication point sort them out by which CA issued them or issued the EE that signed them pick the group that is associated with the CA that issued the EE that signed the manifest. check the manifest listing against that group Would it be good to actually mention this? (Presuming it is correct.) --Sandy From gih@apnic.net Fri Dec 4 13:49:33 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 219813A68B8 for ; Fri, 4 Dec 2009 13:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gvt0nq9UF82M for ; Fri, 4 Dec 2009 13:49:32 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [IPv6:2001:dc0:2001:11::199]) by core3.amsl.com (Postfix) with ESMTP id 7D9D73A68AE for ; Fri, 4 Dec 2009 13:49:30 -0800 (PST) Received: from [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a] (unknown [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 0CCDED58BF; Sat, 5 Dec 2009 08:01:18 +1000 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Geoff Huston In-Reply-To: Date: Sat, 5 Dec 2009 08:49:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <561C85BE-93DF-48F2-9BDE-B417C1693C3C@apnic.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: Re: [sidr] comments on draft-ietf-sidr-rpki-manifests-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Dec 2009 21:49:33 -0000 WG co-chair hat OFF As a co-author of this draft I would like to respond to these comments. On 03/12/2009, at 12:27 PM, Sandra Murphy wrote: > In reviewing the repository structure draft, I was looking at the = manifest draft to see if it answered some of my questions. I came up = with the following comments on the manifests draft. This doesn't imply = that I've done a full review of the manifest draft. >=20 > These comments are made strictly as working group member. I do not = make these comments as wg chair. Wg chair hat off. >=20 >=20 >=20 > comments on draft-ietf-sidr-rpki-manifests-05.txt >=20 > (1) Multiple manifests >=20 > It appears to me that the algorithm described in the manifest = document: >=20 > 3. Check that every file at the publication point appears in one = and > only one manifest, and that every file listed in each manifest > appears at the publication point. >=20 > implies that the union of the manifests matches the union of the = objects at the publication point. So if multiple CAs publish in the = same publication point, one manifest might list some of the objects = produced by one CA and some of the objects produced by another, as long = as another manifest associated with the other CA includes all the other = objects produced by that CA. >=20 > I don't think that is the intent. I thought a manifest was specific = to one CA and listed all that CA's objects but no other CA's objects. = Other language in the document says that a manifest contains objects = associated with one CA. But this is the definitive text, and it would = be good to have it precise. >=20 I believe that section 2 of this document is already clear on this. I = won't reproduce the text here, but I note that the text in section 2 = covers the situation of multiple CA's using the same repository = publication point. It is true that the pseudo algorithms in sections 7 and 8.1 are not = complete, in that an implementor that relies on these sections and only = these sections to construct an implementation would not apply the = necessary tests to validate that the constraints in section 2 apply. > (2) Manifests >=20 > The document says that multiple CAs might publish objects in the same = publication point. Manifests are supposed to list all objects produced = by one CA. If there is just one CA publishing in a publication point, = that's easy - retrieve all files from that publication point and compare = to the manifest. >=20 > If there are several CAs that publish to one publication point, what = is the algorithm for the manifest to be checked? I'd guess: >=20 > download all objects from publication point >=20 > sort them out by which CA issued them or issued the EE that signed = them >=20 > pick the group that is associated with the CA that issued the EE that > signed the manifest. >=20 > check the manifest listing against that group >=20 > Would it be good to actually mention this? (Presuming it is correct.) I believe you are referring to the algorithm section 8.1, and step 3 in = particular. It appears that what you are wanting to do is provide some = form of algorithm for checking the Manifest Scope, as defined in section = 2. One way of doing this is to add a new step 5 to the steps listed in = section 8.1 for the draft: "5. Check that the contents of each manifest match the scope constraints = as specified in section 2." I suspect that the process could be further improved by the addition of = the term "current manifest" to delineate between the most recent = manifest issued by a CA (the "current" manifest) and multiple "current" = manifests issued by multiple CAs. The proposed text for the pseudo code is then: 1. For each entity using this publication point, select the entity's current manifest (where the "current" manifest is the manifest=20 issued by this CA having highest manifestNumber among all valid = manifests, and where manifest validity is defined in Section 7). * If the publication point does not contain a valid manifest, see Section 8.2 Lacking a valid manifest, the following tests cannot be performed. =20 2. Check that the current time is between thisUpdate and nextUpdate. * If the current time does not lie within this interval then see Section 8.4, but still continue with the following tests. =20 3. Check that every file at the publication point appears in one and only one current manifest, and that every file listed in each = current=20 manifest that is published at this publication point also is=20 published at the publication point. * If there exists files at the publication point that do not appear on any manifest, or files listed in a manifest that do not appear at the publication point then see Section 8.5 but still continue with the following test. =20 4. Check that listed hash value of every file listed in each current manifest matches the value obtained by hashing the file at = the publication point. * If there exist files at the publication point whose hash does not match the hash value listed in the manifest, then see Section 8.6. 5. Check that the contents of each current manifest match the manifest = scope constraints as specified in section 2. I'd like to confirm with you that the proposed text addresses your = comments - could you please let the WG know if this is indeed an = acceptable approach to the issue you have raised? Geoff WG Co-chair hat OFF From root@core3.amsl.com Mon Dec 7 11:30:02 2009 Return-Path: X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4BCB03A6817; Mon, 7 Dec 2009 11:30:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091207193002.4BCB03A6817@core3.amsl.com> Date: Mon, 7 Dec 2009 11:30:02 -0800 (PST) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-manifests-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2009 19:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-06.txt Pages : 28 Date : 2009-12-07 This document defines a "manifest" for use in the Resource Public Key Infrastructure. A manifest is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, CRL, or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to enable a relying party to detect certain forms of attacks against a repository. Specifically, a relying party that checks a manifest against the signed objects retrieved from a repository publication point can detect "stale" (valid) data and deletion of signed objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-manifests-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-07111556.I-D@ietf.org> --NextPart-- From gih@apnic.net Tue Dec 8 12:55:57 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0E53A6A17 for ; Tue, 8 Dec 2009 12:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFQjppTyQ8kF for ; Tue, 8 Dec 2009 12:55:56 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 2DC283A6967 for ; Tue, 8 Dec 2009 12:55:54 -0800 (PST) Received: from [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a] (unknown [IPv6:2001:dc0:2001:10:226:b0ff:fef0:5d2a]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 022D5D58C4; Wed, 9 Dec 2009 07:04:43 +1000 (EST) From: Geoff Huston Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Dec 2009 07:55:38 +1100 Message-Id: <16665CBD-22FC-4197-A527-1A5BE1FCC99B@apnic.net> To: Sandra Murphy Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: Rob Austein , sidr@ietf.org Subject: [sidr] Request for Working Group last Call - draft-ietf-sidr-rpki-manifests-06 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2009 20:55:57 -0000 WG Co-Chair Hat OFF Sandy, As a co-author of this draft, I would like to advise you that the = authors of this document are of the view that this document is now ready = for a WG Last Call. Could you please conduct a WG last Call on = draft-ietf-sidr-rpki-manifests-06.txt? Thanks, Geoff co-author of this document WG Co-Chair Hat OFF From ggm@apnic.net Mon Dec 14 16:29:15 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 883703A687F for ; Mon, 14 Dec 2009 16:29:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qn6euPJjv2fD for ; Mon, 14 Dec 2009 16:29:14 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id BF4653A6877 for ; Mon, 14 Dec 2009 16:29:14 -0800 (PST) Received: from dynamic243.apnic.net (dynamic243.apnic.net [203.119.42.243]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 25E1FD5909; Tue, 15 Dec 2009 10:38:41 +1000 (EST) From: George Michaelson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 15 Dec 2009 10:28:53 +1000 Message-Id: To: Sandra Murphy Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: [sidr] status of res-cert ad repos-struct documents X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 00:29:15 -0000 Sandy, can I ask what the status of the following documents: draft-ietf-sidr-res-certs draft-ietf-sidr-repos-struct WG last call was timed to end 23 November. -George From bje@apnic.net Mon Dec 14 21:28:43 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0FD3A682B for ; Mon, 14 Dec 2009 21:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dl1yzjBcNxH5 for ; Mon, 14 Dec 2009 21:28:37 -0800 (PST) Received: from asmtp.apnic.net (asmtp.apnic.net [202.12.29.199]) by core3.amsl.com (Postfix) with ESMTP id 2B0863A672E for ; Mon, 14 Dec 2009 21:28:37 -0800 (PST) Received: from [192.168.1.4] (ppp118-208-104-151.lns20.bne4.internode.on.net [118.208.104.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by asmtp.apnic.net (Postfix) with ESMTP id 2A90BD58BB; Tue, 15 Dec 2009 15:38:03 +1000 (EST) Content-Transfer-Encoding: quoted-printable From: Byron Ellacott Content-Type: text/plain; charset=us-ascii Message-Id: Date: Tue, 15 Dec 2009 15:29:28 +1000 To: Sandra Murphy Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: sidr@ietf.org Subject: [sidr] WGLC status for draft-ietf-sidr-rescerts-provisioning X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Dec 2009 05:28:44 -0000 Hi Sandy, I haven't seen a summary of issues requiring attention in = draft-ietf-sidr-rescerts-provisioning posted to the list yet -- could I = ask what the status of this WGLC is, please? Thanks, Byron= From weiler@watson.org Fri Dec 18 08:40:49 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA33C3A69DD for ; Fri, 18 Dec 2009 08:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgGyW5id1Iah for ; Fri, 18 Dec 2009 08:40:49 -0800 (PST) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id D4E493A6889 for ; Fri, 18 Dec 2009 08:40:48 -0800 (PST) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id nBIGeW0Z079224 for ; Fri, 18 Dec 2009 11:40:32 -0500 (EST) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id nBIGeWCE079221 for ; Fri, 18 Dec 2009 11:40:32 -0500 (EST) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 18 Dec 2009 11:40:32 -0500 (EST) From: Samuel Weiler To: sidr@ietf.org In-Reply-To: <20090707115400.112B09A472C@odin.smetech.net> Message-ID: References: <20090707115400.112B09A472C@odin.smetech.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 18 Dec 2009 11:40:32 -0500 (EST) Subject: Re: [sidr] draft-weiler-rsync-uri-00 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Dec 2009 16:40:49 -0000 draft-weiler-rsync-uri passed IESG review yesterday. SIDR may want to cite it in res-certs and other WG drafts. -- Sam On Tue, 7 Jul 2009, Russ Housley wrote: > I think this document can be used as a reference in the SIDR certificate > profile document. > > Russ > > = = = = = = = = > > http://www.ietf.org/internet-drafts/draft-weiler-rsync-uri-00.txt > > Filename: draft-weiler-rsync-uri > Revision: 00 > Title: The rsync URI Scheme > Creation_date: 2009-07-06 > WG ID: Independent Submission > Number_of_pages: 4 > > Abstract: > This document specifies the rsync Uniform Resource Identifier (URI) > scheme. From housley@vigilsec.com Mon Dec 21 10:34:14 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C7E43A6A71 for ; Mon, 21 Dec 2009 10:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpLAglt0dniO for ; Mon, 21 Dec 2009 10:34:13 -0800 (PST) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 07BDD3A6405 for ; Mon, 21 Dec 2009 10:34:13 -0800 (PST) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 21A5AF24009 for ; Mon, 21 Dec 2009 13:34:05 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id gQB3w362ljRb for ; Mon, 21 Dec 2009 13:33:55 -0500 (EST) Received: from THINKPADR52.vigilsec.com (pool-173-66-67-45.washdc.fios.verizon.net [173.66.67.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id C86B3F24001 for ; Mon, 21 Dec 2009 13:34:03 -0500 (EST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 21 Dec 2009 13:33:52 -0500 To: sidr@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20091221183403.C86B3F24001@odin.smetech.net> Subject: [sidr] Fwd: Document Action: 'The rsync URI Scheme' to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 18:34:14 -0000 This provides the scheme for the rsync URIs in the RPKI certificates. Russ >From: The IESG >To: IETF-Announce >Subject: Document Action: 'The rsync URI Scheme' to Informational RFC >Date: Mon, 21 Dec 2009 09:32:43 -0800 (PST) >Cc: Internet Architecture Board , > RFC Editor > >The IESG has approved the following document: > >- 'The rsync URI Scheme ' > as an Informational RFC > >This document has been reviewed in the IETF but is not the product of an >IETF Working Group. > >The IESG contact person is Ross Callon. > >A URL of this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-weiler-rsync-uri-01.txt > >Technical Summary > > URIs were previously defined in RFC 2396, which was updated by RFC > 3986 [RFC3986]. The procedures for registering new URI schemes are > defined in RFC 4395 [RFC4395]. This URI scheme is already in active > use in the world, but it has never been registered with IANA. This > document makes a provisional registration of the URI scheme that's > already in use. > >Working Group Summary > > Review was requested from the URI-review list in early July. There > is strong consensus on the need for this document (see PROTO writeup > by Dave Ward in the ID tracker). > >Document Quality > > The document has been well reviewed. > >Personnel > > Dave Ward and Russ Housley are the Document Shepherds for this > document. Ross Callon is the Responsible Area Director. > >RFC Editor Note > > Please replace the last sentence of Section 1. > > OLD: > > This document defines a URI scheme for rsync. > > NEW: > > The rsync utility provides fast incremental file transfer [rsync]. > This document defines a URI scheme for rsync. > > Add an informative reference for [rsync]. > > ADD: > > [rsync] http://rsync.samba.org/. > > Please update the first paragraph of Section 2, adding a new sentence. > > OLD: > > This section contains the registration template for the rsync URI > scheme in accordance with RFC 4395 [RFC4395]. > > NEW: > > This section contains the registration template for the rsync URI > scheme in accordance with RFC 4395 [RFC4395]. This URI > scheme is for the rsync protocol using TCP as the transport > protocol. Other transports, such as rsync over SSH, > are not supported by this URI scheme. > > Please add the following paragraph at the send of Section 4. > > ADD: > > Many security considerations for the usage of URIs are discussed in > Section 7 of [RFC3986]. The considerations about reliability and > consistency, malicious construction, rare IP address formats, > sensitive information, and semantic attacks all apply to rsync URIs. > The considerations about transcoding do not apply. The rsync URI > scheme has no particularly unique security considerations. > > The security considerations of the rsync protocol are not covered > in this document. > > Please add a reference to RFC 5234 in Section 2. > > OLD: > > The rsync URI follows the general syntax from RFC 3986 and is > defined by the following ABNF: > > rsyncurl = "rsync:" hier-part > > NEW: > > The rsync URI follows the general syntax from RFC 3986 and is > defined by the following ABNF [RFC5234]: > > rsyncuri = "rsync:" hier-part > > Please include a reference for RFC 5234 in Section 5. > > ADD: > > [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for > Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. > > On the title page, please change Dave Ward's affiliation to be > "Juniper Networks". > > In the author's address section, please change Dave Ward's address to: > > David Ward > Juniper Networks > 1194 North Mathilda Avenue > Sunnyvale, California 94089-1206 USA > Email: dward@juniper.net > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From randy@psg.com Mon Dec 21 11:05:43 2009 Return-Path: X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D77028C16C for ; Mon, 21 Dec 2009 11:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aj4-idYjI9qU for ; Mon, 21 Dec 2009 11:05:42 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 13CB728C167 for ; Mon, 21 Dec 2009 11:05:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NMnZL-000D5N-Lf; Mon, 21 Dec 2009 19:05:23 +0000 Received: from rmac.local.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id D15D42CD22A7; Tue, 22 Dec 2009 04:05:22 +0900 (JST) Date: Tue, 22 Dec 2009 04:05:22 +0900 Message-ID: From: Randy Bush To: Russ Housley In-Reply-To: <20091221183403.C86B3F24001@odin.smetech.net> References: <20091221183403.C86B3F24001@odin.smetech.net> User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] Fwd: Document Action: 'The rsync URI Scheme' to Informational RFC X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Dec 2009 19:05:43 -0000 > This provides the scheme for the rsync URIs in the RPKI certificates. thank you, sam, and dave. randy