OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [wss] Proof-of-Possession


Thomas,

I think I see at least some of what you are getting at.

Do you have specific changes you would recommend?

It looks like you are suggesting (at least) :

1. a change to the definition of POP.

2. a distinction be made between POP and a signature (if appropriate),

3. the binding docs not use headings like "POP of a security token"

All of these seem reasonable to me.

We started with the following definition of POP:

Proof-of-Possession  The proof-of -possession information is data that 
is used in a proof
process to demonstrate the sender's knowledge of information that SHOULD 
only be known to 180
the claiming sender of a security token. 181

Comments: "should only be known" is likely not true when the thing
being proved is a symetric key, and a proof of possession can be fabricated
and sent without a security token. It also seems that any definition of POP
should also account for proving possession of something other than 
knowledge;
such as a token card.

It may be prudent for us to remove the POP term from our specs.
For example in response to comment 2, we could rewrite the cited 
paragraph to the following:

Signatures are also used by message senders to demonstrate knowledge of 
the key claimed in a
security token and thus to authenticate or bind their identity (and any 
other claims occurring in the 247
security token) to the messages they create. A signature created by a 
message sender to 248
demonstrate knowledge of an authentication key serves to authenticate 
the signed message content.

Ron

> 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.
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC