Re: [dss] requirements draft 4

[Trevor Perrin <trevp@trevp.net>]

At 08:46 AM 5/2/2003 -0400, jmessing wrote:

>The distinctions you have drawn undoubtedly should be refined but some of 
>the items you have listed are useful generally for continued discussion 
>purposes.
>
>You wrote:
>
> >So I sort of think we have a 3-layer stack:
> >
> >  Signature Profiles
> >---------------------
> >  Core DSS Protocol
> >---------------------
> >  Protocol Bindings
> >
> >The Core Protocol specifies the mechanics of sending data to be signed or
> >verified and receiving the result.
> >
> >Protocol Bindings specify how transport, authentication, confidentiality,
> >and integrity are supplied to the core protocol.
> >
> >Signature Profiles specify the interpretation of signatures produced by the
> >core protocol.
> >
> >I think we should first tackle the core protocol, since that's the one
> >piece everything depends on - then we (and other people) could supply
> >bindings and profiles to make the core protocol useful in particular
> >environments.
> >
> >
>In designing the DSS protocol, care should be taken to distinguish signing 
>from verification.
>
>With regard to signing, authentication of the signer is paramount. This 
>statement is equally applicable to a single shared key of an enterprise as 
>it is to a multi-user XKMS service. A relying party must know the degree 
>to which it can trust an identity assertion of a DSS in order to determine 
>the suitability of a generated signature to its needs. It will also need 
>to know, where an individual signs on behalf of another person or entity, 
>that the signature has been properly authorized.
>
>However, authentication of identity and authorization will not play a part 
>in a signature verification by a relying party, who will only verify the 
>cryptographic signature of the DSS. Verification of a legal signature 
>should only have to involve cryptographic verification of the key and 
>where relevant, the certificate chain. All the rest is based upon trust by 
>a relying party in the DSS. This trust is the primary commodity that the 
>DSS will offer to users.
>
>Therefore, your apparent concerns are unfounded, IMO, that allowing the 
>DSS protocol to specify various incompatible authentication mechanisms may 
>complicate interoperability and thus "open a can of worms". A relying 
>party will trust the DSS's statement of how it authenticated a signer 
>without having to verify the authentication on its own.

This last statement shows we may be talking about different things.  I 
don't expect the relying party to "verify the authentication on its own" - 
I expect it to "trust the DSS's statement of how it [the DSS] authenticated 
a signer", like you said.

However for the relying party to do so, the relying party must be able to 
*read* the DSS's statement of how it [the DSS] authenticated the 
signer.  If the DSS says "the requestor is Bob, and he authenticated to me 
with his password on the 3rd of April" in Spanish, and the relying party 
only understands Korean, then this statement is of no use to the relying party.

That's why I think there's a need for a single syntax each for expressing 
the requestor's name, and for expressing details of how he authenticated (a 
simple one for just giving the requestor's name, and a more complex one 
(like SAML) for giving authentication details).

But I also now think issues of signature contents like this don't affect 
the core protocol, and should be handled separately in documents that 
specify "signature profiles" - so if one community wants to make SAML the 
lingua franca for authentication details that's fine, and if another 
community wants to use something else that's fine too.


>Whether the authentication information is semantically expressed as SAML, 
>or WSS, or another way, the relying party will necessarily trust the DSS 
>in this regards. It has no way to verify the authentication method on its 
>own, and likely has no interest.
>
>Therefore, your attempts to shoehorn all authentications into a SAML 
>syntax to avoid interoperability issues is based upon a false premise.
>
>If later a signer claims that he or she is not properly associated with a 
>transaction, then with regard to authentication, the problem should be 
>that of the DSS, not the relying party, because that assurance is what the 
>relying party purchased.
>
>It is therefore important to provide in the protocol standardized ways of 
>expressing the trust relationships to a relying party so that it knows 
>what it has purchased by way of assurance, can do "comparison shopping" 
>based upon clearly understood terms,  and can provide understandable proof 
>to a court later in ways that are uniformly expressed through a DSS protocol.
>
>If you proceed to develop a DSS protocol solely as a technical matter upon 
>which later other levels, including assurance levels, can be engrafted, 
>then a risk is created of missing an ingredient that is needed later in 
>the process, and winding up with a perfectly designed technical 
>specification that in the end has little real world use and will have to 
>be redesigned from scratch.

I think separating out "additional signature contents and their semantics" 
from the core protocol is straightforward - as long as nothing in the core 
protocol precludes the DSS from attaching whatever additional attributes it 
wants to the signature, with whatever meaning it wants, I don't see what 
ingredients we might miss.

Trevor