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

On Sun, Oct 30, 2016 at 2:03 PM, Chris Wendt <chris-ietf@chriswendt.net>
wrote:

> Hi Eric,
>
> Thanks.  Answers inline.
>
> -Chris
>
> On Oct 29, 2016, at 7:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> 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?
>
>
> 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.
> 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.
>
>
> 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:alice@example.com",
>                   "sip:bob@example.net"]
>           },
>           "iat":"1443208345",
>           "orig":{"tn":"12155551212"}
>       }
>
> This indentation seems weird. Should you be outdenting the "uri" line.
>
>
> Simple format problem, fixed.
>
>
> S 5.2.2.
> Given the ambiguity about multiple fingerprints, you should probably
> cite the 4572-bis draft.
>
>
> Added.
>
>
>
> 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"?
>
>
> The “using protocol” was a suggestion from JP, so i’ll let him answer that.
>
> 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?
>
>
> good point :) fixed.
>
>
>
> 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.
>
>
> 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?
>

That looks like it should be right.

-Ekr

>
>
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir
>
>
>