Subject: Re: What non-repudiation is not and the PA bit, was Re: To Be,or NR To Be ...

From: "Bob Blakley" <[email-masked]>
Date: Wed, 18 Aug 1999 17:15:32 -0500

Tony,

>>But I disagree that what it is is proof of authentication.  Let me give an
>>example.  Imagine that I'm using SET to initiate a transaction with a
>>merchant.  SET has a mode in which my name & credit card number
>>are not divulged to the merchant -- all the merchant gets is a NR token
>>demonstrating to the cardholder's bank (the issuer) that it should pay
>>the merchant's bank (the acquirer) the sum listed in the token from the
>>account (which the issuer is able to extract from the token).
>>
>>In this scenario, when the merchant receives the token, not only is
>>there no *proof* of authentication, there's no authentication, and in
>>fact there's not even any identification.  Yet there IS non-repudiation
>>evidence, and the merchant *can* use this evidence.
>
>(I am expert in a different SET theory;)
>
>When you say there is no authentication/(or even identification), I believe
>you must be using these terms in the limited sense "this was demonstrably
>signed by Tony."  I tend to apply the terms authentication and identity
>a bit more broadly, even in the PKI context.
>
>To stick with your example:
>
>1.  Your part in the transaction helps produce the "NR-token".  Ostensibly,
>    I could not produce such a token and present it to the merchant so that
>    your account would be charged.  Thus, your uniqueness must come to bear.

This is correct.  But the merchant doesn't get my identity, or have it proven
to him.
So no authentication has taken place, and nothing is proven (neither
authentication
nor anything else) to the merchant.  Similarly, since authentication didn't
take place,
it isn't proven to the acquirer or the issuer either.

>2.  The merchant receives and can forward this token to (your issuing) bank.
>    The token, or some associated instrument, must convey the identity of
>    the merchant's bank to your bank, so that it will authorize the funds
>    transfer.  Again, ostensibly, this must be a tamperproof process so
>    that the funds cannot be misdirected.
>
>Suppose, in one case, the merchant forwards the SET token, but the bank
>decides (somehow) that this token is forged, and refuses to make payment.
>(How would it ever know, if authentication were not involved?)

In fact it does nothing to authenticate the user.  It simply validates the
token,
checks to see if a credit hold has been put on the account number in the
token, and (if no hold has been placed and the charge is under that account's
remaining credit limit) transfers the funds to the acquirer for credit to the
merchant's account.

>OK, here the transaction would break, the merchant would not deliver the
>goods to you in the first place, so no loss.  Clearly this protocol must
>enforce (merchant/merchant's bank) is satisfied in order for the transaction
>to complete.

The protocol checks the validity of the cert. whose corresponding private key
was used to sign the request.

>Suppose it does, but you never receive the ordered merchandise.  You take
>issue with the merchant, who declares they have never had any dealings
>with you at all.  Where is the evidence that YOU were a party to the
>transaction?

That's a different matter; what you want in that case is a different piece of
NR
evidence, specifically non-repduiation of receipt of the order.

>Alternately, if I were to claim to be the "you" in the transaction, and
>complain that I have not received the promised goods, how might the
>merchant demonstrate that it could not have been me?

Again, that's a different matter.  If the goods were electronic, this dispute
either couldn't arise, or the merchant would simply tell the customer to
cancel his (stolen) credit card number.  If the goods were physical, the
merchant keeps a record of the ship-to address.  If it's correct, then (as
today)
some presumption (if traceable shipping was not requested) governs whether
you were assumed to have received the goods or not.  If it isn't correct, then
again the merchant will probably tell you to take the matter up with your
credit-card issuer, under the assumption that your card has been stolen.

--bob

Bob Blakley ([email-masked])
Chief Scientist, Dascom

---

From: Tony Bartoletti <[email-masked]>
Date: Wed, 18 Aug 1999 16:58:31 -0700

Bob,

Thanks for the explanation regarding SET.

By my understanding, The merchant constructs a token, containing
info that identifies the merchant and a transaction, and that token
is signed by the buyer with a key (certified by the bank?) that
contains nothing more than "belongs to cardholder 92874892983749",
a number that has meaning only to that bank.

So the merchant has no interest in the identity of the keyholder.
Indeed, the merchant has no interest in whether the key used by
the supposed buyer is authentic or not.

Rather, the merchant IS interested in whether the bank will find
the token to be authentic, as the completion of the transaction
is dependent upon it.  I would also suppose that this merchant
would be unhappy to submit such a token, and have a fraudulent
reply (appearing as if from the bank in question) stating that
the token was honored, when in fact it was not.

I assume the merchant has some means to protect themselves from
such an occurance.  Perhaps the bank's reply is signed by the
bank's key, and verified by the merchant.  If so, then this is
the case where the merchant would desire NR, and indeed would
want to be able to prove it in court if the bank were to deny
having issued that response.

If anyone here wanted NR with respect to the buyer, it would be
the bank itself, which I assume would not hand out account
signature keys without some such agreement.  But as Ed has
pointed out, things get a bit simpler when the issuer is
also the verifier.

Am I on the right track?

___tony___

Tony Bartoletti                                             LL
IOWA Center                                              LL LL
Lawrence Livermore National Laboratory                LL LL LL
PO Box 808, L - 089                                   LL LL LL
Livermore, CA 94551-9900                              LL LL LLLLLLLL
phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
email: [email-masked]                                   LLLLLLLL

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 19 Aug 1999 12:23:45 +0200

All,

I have just received a mail from Magnus Nyström, RSA who writes:

Magnus> "I would suggest that you include 'pseudonym' as a possible
attribute (in the subject field). The text now talks about using 
pseudonyms inside commonNames although you (almost) have defined 
a pseudonym ATTRIBUTE in 3.2.1, which is confusing and 
inconsistent."

Magnus> "Several of the personal data attributes, in particular perhaps the
'pseudonym' one, appears to be useful constructs, but would be so even
more if they were defined as true attributes and not as
'almost-attributes' as they currently are (no matching rules, for
example). That would make it possible to include them in distinguished
names, for example. In order to give them broader visibility and
useability I suggest that you define them as ordinary attributes. As an
alternative (which also perhaps would be beneficial from a visibility
standpoint) we could define them in the upcoming PKCS #9 v2.0, "Selected
Attribute Types". I do not think this would slow down your progress, as
that version of PKCS #9 is scheduled for release in Q4 this year. You
could get an OID in the RSA tree from me and use a simplified attribute
definition for the time being which then could be expanded in PKCS #9 v2.0
if you think that is a better solution."

My comment>
The reason why we didn't include any of the new attributes in the subject
field was that we didn't want to cause problems for the installed base of
products (including directory systems), which understands the attributes in
RFC 2459, but would get into trouble if new attribute were introduced in
the subject field.

I must say that I'm not 100% sure if this fear is justified, or if we
actually should go along with Magnus proposal and introduce the pseudonym
as an optional attribute in the subject field.

If this attribute were defined in PKCS #9 we may face another situation
where this attribute is more widely accepted and maybe this could be a good
reason to include it. If this is the case, we would have to expand the
supported attributes list of RFC 2459. This could be done in the QC spec
but it could also be an issue to consider in RFC 2459 (if that is formally
possible).

I would like the lists comments on this.

/Stefan

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 20 Aug 1999 17:15:27 +0100

Stefan, Magnus

I quite like the idea of a pseudonym attribute type, since we then 
have proper semantics attached to the attribute value. Otherwise we 
leave it to the certificate user to infer that one value of common 
name is a pseudonym and another value is a real name. This is 
easy for values like "batman" but not for values like " John Smith". 
So if CAs are to issue certs for pseudonyms, let this be publicly 
stated by the pseudonym attribute type in the subject field.

David

***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email [email-masked] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: [email-masked] (Bodo Moeller)
Date: Wed, 1 Sep 1999 00:49:57 +0200 (CEST)

Bob Blakley <[email-masked]>:
> Tony Bartoletti <[email-masked]>:
>> Bob Blakley <[email-masked]>:

>>> [...] SET has a mode in which my name & credit card number

> [...] the merchant doesn't get my identity, or have it proven to
> him.  So no authentication has taken place, and nothing is proven
> (neither authentication nor anything else) to the merchant.  [...]

This is again "authentication" in the limited sense that implies
identification, which seems to be the only disagreement here (in the
parts that I quoted).  But the merchant certainly knows in some sense
that the signature is "authentic", which is the point in providing a
signature in the first place: Even if they cannot determine the
signer's identity as it would appear in typical naming schemes
(e.g. name and address), they know that it's a genuine signature from
someone.  Thus, using the term "authentication" seems appropriate.
(If one wanted to be etymologically correct, however, one could not
even speak of a "signature" here because signatures are really about
identity.)

The word "proof" in "proof of authentication" refers not to the
relying party's being able to convince *themself* of the authenticity,
but to their ability to deliver such proof *to others* (i.e. this is
about what is, if just cryptographical aspects are considered, the
essential difference between digital signatures and symmetric
authentication -- the relying party can fake symmetric authenticators,
but not digital signatures).