Subject: [stir] Review of draft-ietf-stir-passport-09

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Oct 2016 22:32:16 +1100

OVERALL
This document would be easier to read if it came with an example
at the beginning (perhaps the one in 9.1).

I've also been thinking about the use of a URL here. This has
the result that it doesn't bind the certificate itself into the
digital signature, but only the URL. So this implies that it's
at least potentially possible to substitute one certificate
for another with the same private key. Is that a concern here?

S 4.3.
Certificate chains are generally self-validating, so can you explain
why you need HTTPS here? Clearly, it's good practice for confidentiality
and to prevent other forms of attack, but still.

S 5.2.
   {
   "dest":{
          "tn":["12125551212"],
              "uri":["sip:[email-masked]",
                  "sip:[email-masked]"]
          },
          "iat":"1443208345",
          "orig":{"tn":"12155551212"}
      }

This indentation seems weird. Should you be outdenting the "uri" line.

S 5.2.2.
Given the ambiguity about multiple fingerprints, you should probably
cite the 4572-bis draft.

S 7.
    The using protocol of the compact form of PASSporT MUST

This "using protocol" language is pretty odd. Maybe define a specific
term somewhere else? "application protocol"?

S 9.
   JSON, as a canonical format, can include spaces and line breaks, and
   key value pairs can occur in any order.

Doesn't this mean that JSON isn't canonical?

S A.1, A.2

These aren't actually X.509 structure. Also, the private key in S 8.1
is in an OpenSSL-specific structure. Could you encode it in PKCS#8.

---

From: Chris Wendt <[email-masked]>
Date: Sun, 30 Oct 2016 17:03:53 -0400

Hi Eric,

Thanks.  Answers inline.

-Chris

> On Oct 29, 2016, at 7:32 AM, Eric Rescorla <[email-masked]> wrote:
> 
> OVERALL

Other than stolen private key scenarios, which are a concern whether you use URL or not, I’m not sure of a reason why someone would want to do this for legitimate reasons and there would be any concern for multiple certificates being able to validate a call, or whether someone with legitimate access to the private key and would want to use this technique illegitimately would be a valid scenario unless they are a bad actor in the first place.

> and to prevent other forms of attack, but still.

https://tools.ietf.org/html/rfc7515#section-4.1.5 <https://tools.ietf.org/html/rfc7515#section-4.1.5> does call for it.  I could certainly remove the direct reference to this fact and leave it to the generic reference to RFC7515.  It also technically calls for server identity validation using RFC6125 as well.

> 
> 
> S 5.2.
>    {
>    "dest":{
>           "tn":["12125551212"],
>               "uri":["sip:[email-masked] <mailto:[email-masked]>",
>                   "sip:[email-masked] <mailto:[email-masked]>"]
>           },
>           "iat":"1443208345",

Simple format problem, fixed.

> Given the ambiguity about multiple fingerprints, you should probably

Added.

> term somewhere else? "application protocol"?

The “using protocol” was a suggestion from JP, so i’ll let him answer that.

> Doesn't this mean that JSON isn't canonical?

good point :) fixed.

> is in an OpenSSL-specific structure. Could you encode it in PKCS#8.

Ok so I’ll do this:

openssl pkcs8 -topk8 -nocrypt -in key.pem -out p8file.pem

-----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY——

Correct?

> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 30 Oct 2016 14:58:34 -0700

On Sun, Oct 30, 2016 at 2:03 PM, Chris Wendt <[email-masked]>
wrote:

> Other than stolen private key scenarios, which are a concern whether you
> use URL or not, I’m not sure of a reason why someone would want to do this
> for legitimate reasons and there would be any concern for multiple
> certificates being able to validate a call, or whether someone with
> legitimate access to the private key and would want to use this technique
> illegitimately would be a valid scenario unless they are a bad actor in the
> first place.
>

Sorry for not being clear: my concern is that this might be used as an
attack. I don't immediately have one to hand, but....

-Ekr

S 4.3.
> https://tools.ietf.org/html/rfc7515#section-4.1.5 does call for it.  I
> could certainly remove the direct reference to this fact and leave it to
> the generic reference to RFC7515.  It also technically calls for server
> identity validation using RFC6125 as well.
>
>
>
>
> S 5.2.
>    {
>    "dest":{
>           "tn":["12125551212"],

That looks like it should be right.

-Ekr