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

[Michael Hammer <[e-mail]>]

Ummm….

 

If any signature can be repudiated by the sender, 

then how do you apply any consequences for bad behavior?

Any caller could just say, it wasn’t me and they are off the hook?

 

Isn’t the consequence tree:

-          Not signed:  customer may not answer or caveat emptor

-          Signed, robocall:  crackdown

-          Signed, normal call:  good to go?

 

I assume that a signed call that has faulty credentials, 

e.g. bad timestamp, unknown signer, could get filtered out.

But, that gets into carrier policy that can’t be standardized.

 

________________________________

Michael Hammer

[e-mail] <mailto:[e-mail]> 

[phone]


© 2016 Yaana Technologies, LLC. All Rights Reserved. Email confidentiality notice. This message is private and confidential. If you have received this message in error, please notify us and remove it from your system.

 

From: stir [mailto:[e-mail]] On Behalf Of Eric Rescorla
Sent: Saturday, August 27, 2016 9:54 PM
To: Dave Crocker <[e-mail]>
Cc: Chris Wendt <[e-mail]>; [e-mail]
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

 

 

 

On Sat, Aug 27, 2016 at 6:46 PM, Dave Crocker <[e-mail] <mailto:[e-mail]> > wrote:

On 8/27/2016 5:19 PM, Eric Rescorla wrote:

    And I believe that was my original guess, although my very limited
    understanding of non-repudiation includes the significant burden of
    having the timestamp, itself, be validated by an independent
    authority. Otherwise, the signer could claim any time they want to...


That doesn't seem correct to me, at least if "independent" means someone
other than the relying party. The signature is itself a proof attaching
the signer's private key to the passport and to a claim by the signer
about the passport object's assertions being valid at the time in the
timestamp. If the relying party checks the timestamp and rejects it if
it has a bogus timestamp, then any acceptable passport will be
relatively fresh and thus will be usable as a proof of the signer's
representation at the relevant time. Overall, this seems less important
than the freshness property wrt authentication, but it's still a
technical property.



This sounds pretty much the same as authentication.

While the verifier might decide that the timestamp is ok, if the verification is close enough in time to that claimed occurrence, it does nothing for being able to prove the timing to a third-party, /later/.

 

Well, what you can prove (at any time in the future) is that the signer claimed that a given thing was true at (what it claimed was) a given time. You can prove this to a third party.

 

This isn't a necessary property of authentication. For instance, the relying party could share a key with the passport generator and the passport could be secured with a MAC.

 

 

And that's the environment I'm used to hearing about needing 'non-repudiation' for.

In that case, the timestamp needs to have validation that is independent of the signer.  What I'm used to hearing, for that, is that an independent timestamp service does a kind of notary signature on the original signer's stuff, including the timestamp.

 

I'm not sure why you think non-repudiation needs a notary signature. That's not generally the case, as indicated above, and even if you do have a timestamping service, all it can prove is that the signature was generated *prior* to a given time, not at a given time.

 

 

Anyhow, all of seems to go beyond STIR's needs, suggesting that it would be best to remove use of the term?

 

Yes, I think that would be fine.

 



d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net <http://bbiw.net>