Thomas,
It appears that having a precise glossary of terms and their
definitions would be most helpful. Then it would be possible to
evaluate if a term were used properly in the document. And
missing from your note below perhaps are definitions for
"authentication key", "message authenticator", "claimed
identity", and "subject confirmation".
I note that ISO requires in its standards that it must be possible
to directly substitute the complete definition of a term where the
term is referenced in the text. This rule allows reviewers to
determine if the term is used correctly.
Using this rule and the definitions of "Proof-of-Possession"
on lines 208-9 and "Signature" on line 210, I should be able to
rewrite the sentence in lines 248-250 as follows, and have it
actually make sense:
A cryptographic binding between
authentication data that is
provided
with a message to prove that the message
was sent and or created by
a claimed identity and a digest created by a message sender
to
demonstrate knowledge of an authentication key is referred to as
authentication data that
is provided with a message to prove that the
message was sent and or created by a claimed identity and may
serve
as a message authenticator if the cryptographic
binding between
authentication data that
is provided with a message to prove that the
message was sent and or created by a claimed identity and a digest is
performed over the message.
Proof-of-Possession is underlined and italicized above, and the lowercase
spelling of this term in the definition of Signature is assumed to be equivalent
to the uppercase term. I cliped out a couple of articles to make it read
better.
But this text appears to contain circular defintions. If I crunch it down
a
bit by shortening the definition of Proof-of-Possession to "authentication
data", I get
A cryptographic binding between
authentication data and a digest created
by a message sender to demonstrate
knowledge of an authentication key
is referred to as authentication data and may
serve as a message authenticator
if the cryptographic binding between
authentication data and a digest is
performed over the message.
There are other problems with this text as well - the "and or". Proof that
I
sent a message seems to me to in no way prove that I created the message,
if that is what this phrasing is supposed to mean. I would prefer to see
us
drop the "and or created".
Then there's "is referred to as". Not as strong an assertion perhaps as "is
defined as".
If I substitute in the definition of Signature, "authentication data" for
the
term "proof-of-possession" I get the following:
Signature
- A signature is a cryptographic binding between
authentication data and a digest.
I'm not comfortable with this definition of a signature.
Phil
DeMartini, Thomas wrote:
Colleagues,
In order to help us solidify
what we mean by proof of possession, I have prepared the following list of
lines from the specs that talk about proof of possession and have then made
some observations on the consistency of those lines.
Core:
208
Proof-of-Possession - Proof-of-possession is authentication data that is
provided with a
209
message to prove that the message was sent and or created by a claimed identity.
210
Signature - A signature is a cryptographic binding between a proof-of-possession
and a digest.
215
Signature - A signature is a cryptographic binding between a proof-of-possession
and a digest.
248
security token) to the messages they create.
A signature created by a message sender to
249
demonstrate knowledge of an authentication key is referred to as a Proof-of-Possession
and may
250
serve as a message authenticator if the signature is performed over the message.
478
This specification does not dictate if and how subject confirmation must
be done, however, it does
479
define how signatures can be used and associated with security tokens (by
referencing them in
480
the signature) as a form of Proof-of-Possession
1494 When digital signatures
are used for verifying the identity of the sending party, the sender must
1495 prove the possession of
the private key. One way to achieve this is to use a challenge-response
1496 type of protocol. Such
a protocol is outside the scope of this document.
1497 To this end, the developers
can attach timestamps, expirations, and sequences to messages.
Binding Documents:
3 .4
Proof-of-Possession of Security Tokens
Observations:
210/215 say that a signature is a binding BETWEEN a proof-of-possession
and a digest, but 248-250 and 478-480 say that a signature IS a proof-of-possession.
1494-1497 talk about proof
of possession of a KEY, but the bindings have headings for proof of possession
of SECURITY TOKENS and lines 208-209 talk about proof that a message was
sent and or created by a claimed IDENTITY.
In resolving the above two
observations, it may also help to consider whether, in 208-209 (“sent and
or created”), we really mean “sent, created, or both sent and created” or
just “created” or just “sent and created” or “created and intended” or something
else.
&Thomas.
