Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-04.txt

[Kevin J Ma <[e-mail]>]

Hi Kent,

  Read through the updated draft; couple of comments below.

thanx.

--  Kevin J. Ma


- general: "CDNI <XXX> Interface" -> "CDNI <XXX> interface"
           Francois made this comment on the metadata draft, so I
           assume it would apply to url signing as well.

- section 2.4: "encoding sheme" -> "encoding scheme"

- section 3: "step 5a-5b" -> "step 5"
             note: step 4 just says "step 4"

             step 6(A)(c): "an URI" -> "a URI"

             steps 6(A)(e) and 6(B)(e) are not really steps?
             They're just making statements about what the messages look
             like up through steps 6(A/B)(d)?  Should they just be a
             comments?

             steps 6(A)(f) and 6(B)(g): Since the values in the "query
             string" are not actually going to go into the actual URI,
             there's no need to perform URL encoding.  We should just
             remove that text (and possibly add a note about it)?

             step 6(B)(f): Where is the message digest used?

             second step 2: I decoded the base64 encoded value and it
             does not match the value in second step 1?

             "VER=1&ET=1209422976&CIP=10.0.0.1&KID=foobar:keys:123&
              HF=SHA-1&MD=4fb1c1adf1588fbe11cc6a04c6e69f35" !=
             "VER=1&ET=1209422976&CIP=10.0.0.1&KID=example:keys:123&
              HF=SHA-256&MD=4fb1c1adf1588fbe11cc6a04c6e69f35"

             "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEm
              S0lEPWZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00
              ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ==" ->
             "VkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEm
              S0lEPWV4YW1wbGU6a2V5czoxMjMmSEY9U0hBLTI1NiZN
              RD00ZmIxYzFhZGYxNTg4ZmJlMTFjYzZhMDRjNmU2OWYzNQ=="?

- section 4: The first paragraph discusses signing being enabled.
             Should it also mention checking the allowable set of dCDNs?

             in the first step 3, should we check that the VER is
             within the allowable VER set?  If it's not, I assume we
             would want to deny the request?  Should we state that?

             in step 8, if both MD and DS are specified, should we
             deny the request?

             in the second step 1 or 2, not only does the scheme need
             to be removed, but any query string parameters after the
             first URISigningPackage parameter also need to be
             discarded before beginning step 3?

             steps 4(A)(a) and 4(B)(a): if the KID is found but
             doesn't match the metadata config, or if a KID cannot be
             found in either the URISigningPackage or the
             metadata/config, or if the specified KID is not in the
             allowable KID set, I assume we would want to deny the
             request?  Should we state that?

             step 4(A)(b): HF has a default.  Is it expected that the
             default would be part of the config/metadata?  If the
             specified HF is not in the allowable HF set, I assume we
             would want to deny the request?  Should we state that?

             steps 4(A)(f) and 4(B)(e): Since the values were never
             actually in the actual URI, there's no need to perform
             URL decoding.  We should just remove that text (and
             possibly add a note about it)?

             step 4(B)(b): Should there be an extraction step for DSA,
             with consideration for the default value?

             step 4(B)(e): Should this be a digital signature using
             the EC DSA algorithm?

- section 5.4: "URI for a content" -> "URI for content"

- section 5.5: "allowed values are:" should be before the list of values.

- sections 6.1 and 6.2: missing periods in the steps
                        inconsistent "z" usage for authori[s|z]ation
                        (step 4 of figure 4: capitalize Authori[s|z]ation)

- section 6.2: "URI Signing does match" -> "URI Signing does not match"

    "With DNS-based request routing, URI Signing does match well the
     general chain of trust model of CDNI when used with symmetric keys
     because the symmetric key information needs to be distributed across
     multiple CDNI hops including non-adjacent hops."

- section 9: "approriate" -> "appropriate"
             "In general it" -> "In general, it"

> -----Original Message-----
> From: CDNi [mailto:[e-mail]] On Behalf Of Kent Leung (kleung)
> Sent: Thursday, February 13, 2014 8:27 PM
> To: [e-mail]
> Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-
> signing-04.txt
> 
> FYI. This new version addressed some of the issues and comments raised
> during last IETF session. The key changes are:
> 
> - Updated the document to be in line with the new approach of mandatory
> packaging and encapsulated information elements.
> - Only one attribute in the URI query string is used for URI Signing. The
> attribute name is provided by CDNI metadata or via configuration.
> - Adjusted section 2 to make a clear distinction between an information
> element (the three categories) and the packaging attribute.
> - Fixed inconsistencies and errors in the document which addressed Kevin's
> comments
> 
> Kent
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, February 13, 2014 5:08 PM
> To: Ray van Brandenburg; Kent Leung (kleung); Bill Downey; Bill Downey;
> Scott Leibrand; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur
> (flefauch); Ray van Brandenburg; Francois Le Faucheur (flefauch)
> Subject: New Version Notification for draft-leung-cdni-uri-signing-04.txt
> 
> 
> A new version of I-D, draft-leung-cdni-uri-signing-04.txt
> has been successfully submitted by Kent Leung and posted to the IETF
> repository.
> 
> Name:		draft-leung-cdni-uri-signing
> Revision:	04
> Title:		URI Signing for CDN Interconnection (CDNI)
> Document date:	2014-02-13
> Group:		Individual Submission
> Pages:		34
> URL:            http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-
> signing-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-leung-cdni-uri-
> signing/
> Htmlized:       http://tools.ietf.org/html/draft-leung-cdni-uri-signing-04
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-leung-cdni-uri-
> signing-04
> 
> Abstract:
>    This document describes how the concept of URI signing supports the
>    content access control requirements of CDNI and proposes a URI
>    signing scheme.
> 
>    The proposed URI signing method specifies the information needed to
>    be included in the URI and the algorithm used to authorize and to
>    validate access requests for the content referenced by the URI.  Some
>    of the information may be accessed by the CDN via configuration or
>    CDNI metadata.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> The IETF Secretariat
> 
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni