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