Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt
Randy Bush <randy@psg.com> Fri, 25 May 2012 01:29 UTC
Return-Path: <randy@psg.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA6F11E8098 for <sidr@ietfa.amsl.com>; Thu, 24 May 2012 18:29:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.462
X-Spam-Level:
X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7C5Gdzpwk1m for <sidr@ietfa.amsl.com>; Thu, 24 May 2012 18:29:16 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD211E808E for <sidr@ietf.org>; Thu, 24 May 2012 18:29:16 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <randy@psg.com>) id 1SXjL9-000KRM-2y; Fri, 25 May 2012 01:29:15 +0000
Date: Fri, 25 May 2012 10:29:13 +0900
Message-ID: <m2wr412gly.wl%randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Sandy Murphy <sandy@sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F109D5@Hermes.columbia.ads.sparta.com>
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F109D5@Hermes.columbia.ads.sparta.com>
User-Agent: Wanderlust/2.15.9 (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: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 May 2012 01:29:17 -0000
a quick read only. and sorry to wait for wglc, but that's life. at least i did not wait for ietf lc :) -- what is "RPSL"? it is not defined, nor is there a cite. -- 2.1. General Attributes, Meta Information in general, the format/syntax of the attribute part of many fields might be specified more precisely. have mercy on the people who are gonna write code to parse this stuff. e.g. time "is expressed as the decimal representation of an unsigned integer," but what is a decimal representation? ascii? (note that 3.1.4 does this) i'd even settle for examples. the "list of attribute names" needs to cite the enumeration of allowed names, kinda hard if RPSL has no cite. blah blah blah. -- 2.1. General Attributes, Meta Information 2. Reference to the certificate corresponding to the private key used to sign this object (field "c"). This is a URL of type "rsync" or "http(s)" that points to a specific resource certificate in an RPKI repository. needs a cite -- 2.1. General Attributes, Meta Information 3. Signature method (field "m"): what hash and signature algorithms were used to create the signature. The allowed algorithms which can be used for the signature are specified in [RFC6485]. sec folk, is this sufficiently specified that i can get a sure parse? i am three levels deep in rfcs and am still not sure. -- 2.1. General Attributes, Meta Information 5. The signed attributes (field "a"). This is a list of attribute names, separated by an ASCII "+" character (if more than one attribute is enumerated). The list must include any attribute at most once. as rfc 2622 has many attributes which are "multi-valued," which of the set is being signed? -- Optional fields of the "signature" attribute: is it a field or an attribute? both are used. decide. -- One applications for such a mechanism include the case of a route[6] object, where both the prefix owner's and the AS owner's signature is expected (if they are different parties). first, this is an example of why a mild grammar pass is needed. second, the trust model of the rpki ROA is that the AS owner does not attest. i do not remember the trust model in RPSL and am too lazy to try to figure it out as it cites 2725 which says 3. Routes should only be announced with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space. but i just do not have the energy to find how this is stated, validated, ... in this way too looong doc. but the difference in trust models could be at least noted. and i have this nagging worry that there is trouble waiting in that list of urls of certs. the references and referents are not necessarily stable and the resulting instability of a collection of them could be interesting. -- 2.2. Signed Attributes One can look at an RPSL object as an (ordered) set of attributes uh, i guess one could. but my memory is that the are not strictly ordered. you may want to say if and why ordering is actually important to this draft. -- 2.2. Signed Attributes trust model issue. what attributes may [not] be signed by, for example, a prefix cert? may prefix certs [not] sign different fields/attributes than AS certs? -- The type of the object determines the minimum set of attributes that MUST be signed. The signer MAY choose to sign additional attributes, in order to provide integrity protection for those attributes too. forward ref to sec 4 would be helpful here. is integrity the only assertion being made if for signed attributes beyond the minimum set? with multiple signers, is, for example, the AS holder signing an route: object really attesting to the holes: and org:? -- why not mandate the canonic syntax of 3.1.4 in the objects themselves? -- 3.2. Signature Creation 3. Arrange the selected attributes according to the selection sequence specified in the "a" field as above, omiting all attributes that will not be signed. attributes which may be repeated are gonna be fun. -- back to tex randy
- [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.t… Randy Bush
- Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.t… Terry Manderson
- Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.t… Murphy, Sandra
- Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.t… Murphy, Sandra