Subject: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

From: Jim Schaad <[email-masked]>
Date: Thu, 14 May 2015 10:59:04 -0700

Version -05

I probably need to do a more in depth read, however my first comment is that I really dislike the term "non-repudiation"  There is no such thing as non-repudiation, there is only repudiation followed by an attempt to provide that you lied when you repudiated it.

When you say non-repudiation, what are you really trying to imply here? 

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46

---

From: Jim Schaad <[email-masked]>
Date: Sun, 17 May 2015 10:17:33 -0700

Closed #46.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#event-306829398

---

From: Jim Schaad <[email-masked]>
Date: Sun, 17 May 2015 10:17:33 -0700

This shows a good reason why I want to kill non--repudiation.  Your definition of what it means does not match at all well with the version that I was hearing back when I started.  In that world a non-repudiation signature was different than a regular signature, much like your signature at the bottom of a legal document is not the same as your signature on the meeting signing sheet at a F2F meeting.

In the world of SACM, the idea that non-repudiation exists does not seem to be very viable.  For the most part, an entity will be signing based on best guess data as inputs.  If one is going to say that my signature on my work is only as good as the inputs to it are.  What kind of non-repudiation exists?  It is a best guess result that I am staking my reputation on.  Origination of data along with reputation the entity seems to be better concepts to use than non-repudiation.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-102824246

---

From: Jim Schaad <[email-masked]>
Date: Sun, 17 May 2015 10:28:46 -0700

Pressed the wrong button when I added the comment

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-102824837

---

From: Michael Hammer <[email-masked]>
Date: Mon, 18 May 2015 13:52:19 +0000

I think you are conflating two aspects to this.  Being able to verify that a message was not changed in transit (integrity) along with being able to verify that a message came from a known source (non-repudiation) is needed to ensure that a bad actor is not injecting bogus malicious information into a system.  The concept of reliability of the source of the information is different.  The former confirms that you sent it.  The latter judges whether your data tends to be good.  But, given the nature of the system itself, that latter may be acceptable.  BTW, there is both non-repudiation of sender and of receipt.  So, that can work both ways.

________________________________

Michael Hammer

Principal Engineer

[email-masked] <mailto:[email-masked]> 

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

 <http://www.yaanatech.com/> www.yaanatech.com

From: sacm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Sunday, May 17, 2015 1:18 PM
To: sacmwg/draft-ietf-sacm-requirements
Cc: sacm
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-102824246> .  <https://github.com/notifications/beacon/AKbE0WCTH3pregtdHftufPUuInm8oqG3ks5oKMStgaJpZM4EavIS.gif>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 18 May 2015 08:53:41 -0700

What you are calling non-repudiation, I call origination.   One can have a weak version of origination with a MAC, but one can never have what is call non-repudiation.

How can one have non-repudiation of receipt?  The only way I can think of doing so would be for the receiver to generate a new signed message, in which case one is talking about non-repudiation of a sender again and not of receipt.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-103112198

---

From: Michael Hammer <[email-masked]>
Date: Mon, 18 May 2015 16:27:32 +0000

BTW, I am not debating whether such a thing is needed or not, just wanted to clarify the terms meaning based on my experience with military messaging systems.

A hash could provide integrity protection, but for some level of guarantee that a particular sender sent a message, usually a PKI private key is needed to demonstrate that only that key holder could have sent the message.  Pairwise symmetric secret keys could also work, but less reliable.

Origination to me would just mean that someone sent a message, but could be anybody.  But that is just devolving into semantic definitions.  One could define a term to be whatever one likes, if one doesn’t like a more standard one.

Non-repudiation of receipt is done by the recipient taking a hash of the received message, signing it with the receiver’s private key and sending the Ack with the signature back.  The sender can verify that signature using the cert of the receiver.  It’s all about whose private key and cert are used to sign and to verify.

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: sacm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Monday, May 18, 2015 11:54 AM
To: sacmwg/draft-ietf-sacm-requirements
Cc: sacm
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-103112198> .  <https://github.com/notifications/beacon/AKbE0bbCMTAnKkki5YcRxrG-uHI7Lsefks5oKgKFgaJpZM4EavIS.gif>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 18 May 2015 10:47:59 -0700

From: sacm [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Monday, May 18, 2015 9:28 AM
To: reply+00a6c4d1f1a2505b0462[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

[JLS] Yes – any operation of this type will give integrity.  I would actually rate a pairwise symmetric key MAC as being more reliable than a hash for doing integrity.   The definition of integrity is just that the message has not changed from the point which it was sent to the point at which it was received.  Any operation, including a checksum, can be used for this purpose.  The question of how much checking one desires is what controls what method one uses.

[JLS]  That is a fairly weak definition of origination to be using.  You might prefer the term origin of data, but I find Origination to be clear for myself.  I define this as being a method of determining what entity created and sent me the data.   I rather like the definition that can be found in Wikipedia for non-repudiation which is “Non-repudiation refers to a state of affairs where the purported maker of a statement will not be able to successfully challenge the validity of the statement or contract <https://en.wikipedia.org/wiki/Contract> .”  This implies both integrity, origin of data as well as some degrees of assurance about things like intent of the signer.  One of the problems with the use of non-repudiation in the way you are using it is that you then need to ascribe some different meanings in an X.509 signature to the different usage bits of “signature” and “non-repudiation”.  (Note that the “non-repudiation” bit has been re-named to “contentCommitment” in the X.509 drafts, but not in RFC 5280.)  If we are going to use non-repudiation as meaning “signed” then we definitely need to put this into the terminology document as this is not going to be a general understanding for many people.

[JLS] Right, but this is not a function of the original signature, it is building of a signed receipt message and the concept of “non-repudiation” is on the recipient’s signature operation and not on the originator’s signature operation.

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

—

---

From: Michael Hammer <[email-masked]>
Date: Mon, 18 May 2015 18:01:20 +0000

We may also be running into a clash of terminology as used in the communication versus computing worlds.

But, you understand what I was getting at, so will leave it to you to figure where you want to go with it.

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: Jim Schaad [mailto:[email-masked]] 
Sent: Monday, May 18, 2015 1:48 PM
To: Michael Hammer
Cc: [email-masked]
Subject: RE: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

From: sacm [mailto:[email-masked]] On Behalf Of Michael Hammer
Sent: Monday, May 18, 2015 9:28 AM
To: reply+00a6c4d1f1a2505b0462[email-masked]; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

—

---

From: Nancy <[email-masked]>
Date: Wed, 20 May 2015 16:36:53 -0700

Hi,
In the considerations, I did place non-repudiation as out of scope for SACM.  My interpretation of non-repudiation is that there could be legal implications (e.g. deniability by the originator).  That is, just because the receiver was able to authenticate the communication channel and the MAC doesn't really "prove" that it was authentic (from the original sender).....

I don't think there is such a thing to non-repudiation of a receiver??

But Jim:  I included it because there were discussions in SACM to the need for this, and my personal belief is that we can provide some cryptographic means to integrity and authenticity of the message but not "non-repudiation".

Suggestions on how to proceed?  I can remove the last sentence as I'm not really sure how we can provide such mechanisms?

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104071567

---

From: Michael Hammer <[email-masked]>
Date: Thu, 21 May 2015 00:23:40 +0000

Nancy,

This is the equivalent for connectionless messaging of mutual authentication for connection-oriented communications.

And surely, you don’t deny that exists?  (3GPP systems do that)

If you have an underlying layer that uses, say TLS with mutual authentication, then you may not need this at the application layer.  But, to say they don’t exist denies the existence of running code systems that do this.

Now, if you are using non-repudiation to mean something other than an existing meaning, I can’t help you there.

At that point, it is Alice in Wonderland time.

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: sacm [mailto:[email-masked]] On Behalf Of Nancy
Sent: Wednesday, May 20, 2015 7:37 PM
To: sacmwg/draft-ietf-sacm-requirements
Cc: sacm
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Hi,

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104071567> .  <https://github.com/notifications/beacon/AKbE0Y9gpeb4O7yPz0WHk40ngIgynMQBks5oLRIVgaJpZM4EavIS.gif>

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Thu, 21 May 2015 03:24:20 +0000

Hi Mike,

We are misunderstanding each other? See below:

From: Michael Hammer <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 20, 2015 at 5:23 PM
To: "reply+00a6c4d150b8d068a5cb[email-masked]<mailto:reply+00a6c4d150b8d068a5cb[email-masked]>" <reply+00a6c4d150b8d068a5cb[email-masked]<mailto:reply+00a6c4d150b8d068a5cb[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Nancy,

This is the equivalent for connectionless messaging of mutual authentication for connection-oriented communications.
And surely, you don’t deny that exists?  (3GPP systems do that)
[NCW] What is equivalent to connectionless messaging?

If you have an underlying layer that uses, say TLS with mutual authentication, then you may not need this at the application layer.  But, to say they don’t exist denies the existence of running code systems that do this.
[NCW] I’m not sure what you’re referring to “they don’t exist”?  My comment went to my interpretation of non-repudiation which is basically an attestation of an event that the originator can not refute.  That is different than providing authenticity, e.g. Including mutual authentication at the session layer, establishing ephemeral keys and provided key’ed MAC’s that imho provide authenticity but I don’t think it provides non-repudiation.

________________________________
Michael Hammer
Principal Engineer
[email-masked]<mailto:[email-masked]>
Mobile: +1408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com<http://www.yaanatech.com/>

Hi,

—
Reply to this email directly or view it on GitHub<https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104071567>.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 20 May 2015 21:39:26 -0700

I think we are to the point were we need to define a set of terms, put them into the terminology document and use them.  As long as we have defined our terms we should be fine.

The terms I would recommend are:
Integrity
Origin of Data
Confidentiality
Authentication
Authorization

If these terms make sense I will put an issue into the terminology document with definitions.

Like Nancy, I have overloaded garbage on non-repudiation which is why I opened this issue.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104132658

---

From: Michael Hammer <[email-masked]>
Date: Thu, 21 May 2015 13:38:37 +0000

Yes, I'm not perhaps being clear enough.  Let me try again.

I was trying to make an analogy between:

-          What is mutual authentication for connection-oriented? (TLS)

-          What is mutual authentication for connectionless-oriented?
(Messaging)

I figured most people understand TLS mutual authentication, so 

I could show the parallel to gain understanding for the messaging case.

Certificates and signing are used in both cases to "prove" 

who the other party is that is sending or receiving the traffic.

My "don't exist" comment was about the fact that mutual authentication in
TLS 

and non-repudiation of sender and receiver exist in running systems.

You had said that non-repudiation of receipt does not exist.  

I disagreed since I know of systems that do exist.

In the above case, the event that cannot be refuted is the sending of a
specific message that one signed.

As you clarified that your statement applies to your interpretation of the
term, 

I cannot disagree with that, but that is more of a tautological argument.

Hope that helps.

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: Nancy Cam-Winget (ncamwing) [mailto:[email-masked]] 
Sent: Wednesday, May 20, 2015 11:24 PM
To: Michael Hammer;
reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf000000011174dc9592
[email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between
Provider and Requester - Non-Repudiation (#46)

Hi Mike,

From: Michael Hammer <[email-masked]
<mailto:[email-masked]> >
Date: Wednesday, May 20, 2015 at 5:23 PM
To:
"reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf000000011174dc959
[email-masked]
<mailto:reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf0000000111
[email-masked]> "
<reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf000000011174dc959
[email-masked]
<mailto:reply+00a6c4d150b8d068a5cbc0d363310123db1e28949f55b07792cf0000000111
[email-masked]> >,
"[email-masked]
<mailto:[email-masked]> "
<[email-masked]
<mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked]
<mailto:[email-masked]> >
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between
Provider and Requester - Non-Repudiation (#46)

Nancy,

This is the equivalent for connectionless messaging of mutual authentication
for connection-oriented communications.

And surely, you don't deny that exists?  (3GPP systems do that)

If you have an underlying layer that uses, say TLS with mutual
authentication, then you may not need this at the application layer.  But,
to say they don't exist denies the existence of running code systems that do
this.

[NCW] I'm not sure what you're referring to "they don't exist"?  My comment
went to my interpretation of non-repudiation which is basically an
attestation of an event that the originator can not refute.  That is
different than providing authenticity, e.g. Including mutual authentication
at the session layer, establishing ephemeral keys and provided key'ed MAC's
that imho provide authenticity but I don't think it provides
non-repudiation.

Now, if you are using non-repudiation to mean something other than an
existing meaning, I can't help you there.

Michael Hammer

Principal Engineer

Mobile: +1408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: sacm [mailto:[email-masked]] On Behalf Of Nancy
Sent: Wednesday, May 20, 2015 7:37 PM
To: sacmwg/draft-ietf-sacm-requirements
Cc: sacm
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between
Provider and Requester - Non-Repudiation (#46)

Hi,
In the considerations, I did place non-repudiation as out of scope for SACM.
My interpretation of non-repudiation is that there could be legal
implications (e.g. deniability by the originator). That is, just because the
receiver was able to authenticate the communication channel and the MAC
doesn't really "prove" that it was authentic (from the original sender).....

But Jim: I included it because there were discussions in SACM to the need
for this, and my personal belief is that we can provide some cryptographic
means to integrity and authenticity of the message but not
"non-repudiation".

Suggestions on how to proceed? I can remove the last sentence as I'm not
really sure how we can provide such mechanisms?

-
Reply to this email directly or view it on GitHub
<https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomme
nt-104071567> .
<https://github.com/notifications/beacon/AKbE0Y9gpeb4O7yPz0WHk40ngIgynMQBks5
oLRIVgaJpZM4EavIS.gif>

---

From: Michael Hammer <[email-masked]>
Date: Thu, 21 May 2015 13:42:36 +0000

Sounds good.

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: sacm [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Thursday, May 21, 2015 12:39 AM
To: sacmwg/draft-ietf-sacm-requirements
Cc: sacm
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104132658> .  <https://github.com/notifications/beacon/AKbE0YTnKUWT2iUYlChZfXAnaYoogOi2ks5oLVj-gaJpZM4EavIS.gif>

---

From: Ira McDonald <[email-masked]>
Date: Thu, 21 May 2015 09:45:50 -0400

Hi,

I note that reliable connectionless security associations and mutual
authentication
*are* available with Datagram TLS (RFC 6347) - widely deployed - appearing
soon
even in cellular networks with DTLS over SMS work-in-progress.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Thu, May 21, 2015 at 9:38 AM, Michael Hammer <
[email-masked]> wrote:

> Yes, I’m not perhaps being clear enough.  Let me try again.
>
>
>
> Certificates and signing are used in both cases to “prove”
>
> My “don’t exist” comment was about the fact that mutual authentication in
> TLS
>
> *________________________________*
>
> *Michael Hammer*
>
> *Principal Engineer*
>
> [email-masked] <[email-masked]>*
>
> *Mobile: *+1 408 202 9291
>
> 542 Gibraltar Drive
>
> Milpitas, CA 95035 USA
>
> www.yaanatech.com
>
>
>
> *From:* Nancy Cam-Winget (ncamwing) [mailto:[email-masked]]
> *Sent:* Wednesday, May 20, 2015 11:24 PM
> *To:* Michael Hammer;
> reply+00a6c4d150b8d068a5cb[email-masked];
> *Cc:* [email-masked]
> *Subject:* Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between
> *From: *Michael Hammer <[email-masked]>
> *Date: *Wednesday, May 20, 2015 at 5:23 PM
> *To: *"
> reply+00a6c4d150b8d068a5cb[email-masked]"
> <
> reply+00a6c4d150b8d068a5cb[email-masked]>,
> "[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between
> This is the equivalent for connectionless messaging of mutual
> authentication for connection-oriented communications.
>
> to say they don’t exist denies the existence of running code systems that
> do this.
>
> [NCW] I’m not sure what you’re referring to “they don’t exist”?  My
> comment went to my interpretation of non-repudiation which is basically an
> at the session layer, establishing ephemeral keys and provided key’ed MAC’s
> that imho provide authenticity but I don’t think it provides
> non-repudiation.
>
>
>
> existing meaning, I can’t help you there.
>
> *________________________________*
>
> *Michael Hammer*
>
> *Principal Engineer*
>
> [email-masked] <[email-masked]>*
>
> *Mobile: *+1408 202 9291
>
> 542 Gibraltar Drive
>
> Milpitas, CA 95035 USA
>
> www.yaanatech.com
>
>
>
> *From:* sacm [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Nancy
> *Sent:* Wednesday, May 20, 2015 7:37 PM
> *To:* sacmwg/draft-ietf-sacm-requirements
> *Cc:* sacm
> *Subject:* Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between
> In the considerations, I did place non-repudiation as out of scope for
> SACM. My interpretation of non-repudiation is that there could be legal
> implications (e.g. deniability by the originator). That is, just because
> the receiver was able to authenticate the communication channel and the MAC
> <https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104071567>
> .
>
> _______________________________________________
> sacm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sacm
>
>

---

From: Nancy <[email-masked]>
Date: Thu, 21 May 2015 22:42:17 -0700

Agreed!  But then, can we remove non-repudiation then?  I  included it because in previous discussions folks insisted it be there, but as demonstrated in this thread, there are different interpretations of what that means.  The Infosec and CSIRT teams I work with do tell me of the legal implications (e.g. there’s a human aspect to it), but I do see that others believe the PKI signatures could be a form of evidentiary form to serve non-repudiation.

Nonetheless, we do need clarification for SACM’s use of the terms below….and non-repudiation?

Nancy.

From: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Reply-To: sacmwg/draft-ietf-sacm-requirements <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, May 20, 2015 at 9:39 PM
To: sacmwg/draft-ietf-sacm-requirements <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

—
Reply to this email directly or view it on GitHub<https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104132658>.

---
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104518806

---

From: Michael Hammer <[email-masked]>
Date: Fri, 22 May 2015 13:34:19 +0000

If those guys are lawyers, perhaps they could 

come up with a “legal disclaimer” information element.  :)

Michael Hammer

Principal Engineer

Mobile: +1 408 202 9291

542 Gibraltar Drive

Milpitas, CA 95035 USA

From: sacm [mailto:[email-masked]] On Behalf Of Nancy
Sent: Friday, May 22, 2015 1:42 AM
To: sacmwg/draft-ietf-sacm-requirements
Cc: sacm
Subject: Re: [sacm] [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

Nancy.

From: Jim Schaad <[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]> <mailto:[email-masked]>>
Reply-To: sacmwg/draft-ietf-sacm-requirements <[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]> <mailto:[email-masked]>>
Date: Wednesday, May 20, 2015 at 9:39 PM
To: sacmwg/draft-ietf-sacm-requirements <[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]> <mailto:[email-masked]>>
Cc: "[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]%3e> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]%3cmailto:[email-masked]> <mailto:[email-masked]>>
Subject: Re: [draft-ietf-sacm-requirements] 5.1 Trust between Provider and Requester - Non-Repudiation (#46)

—

—
Reply to this email directly or view it on GitHub <https://github.com/sacmwg/draft-ietf-sacm-requirements/issues/46#issuecomment-104518806> .  <https://github.com/notifications/beacon/AKbE0XquzXvdstVOdkCSbn3y4CBzcMT3ks5oLrk5gaJpZM4EavIS.gif>

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 22 May 2015 13:28:41 -0400

Sent from my iPhone

> On May 21, 2015, at 12:39 AM, Jim Schaad <[email-masked]> wrote:
> 

I agree and having origin of data is achievable as opposed to non-repudiation.

Thanks,
Kathleen 
> Reply to this email directly or view it on GitHub.
>