Subject: [stir] Alexey Melnikov's No Objection on draft-ietf-stir-passport-10: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 01 Nov 2016 07:43:43 -0700

Alexey Melnikov has entered the following ballot position for
draft-ietf-stir-passport-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-stir-passport/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is generally a well written and detailed document. Thank you.

I have some minor comments:

5.1.1.  "iat" - Issued At claim

   The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined
   claim Issued At.  As defined the "iat" should be set to the date and
   time of issuance of the JWT and MUST the origination

I think a verb is missing between "MUST" and "the origination"

   of the personal
   communications.

5.2.2.  "mky" - Media Key claim

   2.  Sort the lines based on the UTF8 encoding

UTF-8 needs a normative reference (RFC 3629).

       of the concatenation of
       the "alg" and "dig" claim value strings.

7.1.  Example Compact form PASSporT Token

eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9

I decoded this and it looks reasonable:

{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/passport.cer"}

   .
   eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
   6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0

OpenSSL produced the following:

 {"dest":{"uri":["sip:[email-masked]"]},"iat":

this looks like a truncated value. Is something wrong with the value or
is this an OpenSSL bug?