Re: [dss] comments on DSS requirements

[Trevor Perrin <trevp@trevp.net>]

Hi Frederick,

inline -

At 05:29 PM 7/18/2003 -0400, Frederick.Hirsch@nokia.com wrote:

>Comments on DSS Use Case Requirements, Draft 8, 12-July 2003
>
>---
>2.11 Client side hashing
>
>Wouldn't a recipient of a signature send the entire signature for 
>verification, either with referenced documents, document pointers or 
>document hashes? Sending hashes is not enough, what is to be verified must 
>also be sent.

Right, the recipient should send the signature.  But he doesn't necessarily 
need to send every document the signature is calculated over, that's all 
this was trying to say.


>----
>2.12 Time stamps
>
>The time stamp use cases included a number of variations that suggest 
>additional cases, such as the following:
>
>Verification: Verify that signature was valid at the specified time, both 
>in terms of certificate/key validity period as well as certificate 
>validation at that time.
>
>(Re use case document 3.3 [243],

Since this is in the requirements part of the doc, I'm not sure we need to 
reflect it in the Use Cases part.  In any case, it wouldn't go under 2.12, 
since verifying at a particular time doesn't necessarily have anything to 
do with timestamps, it might just mean checking a CRL that the key was 
still valid at that time.


>I do not understand why a item needs to be re-signed periodically given 
>certificate validity expiration - can't the old key still be used to 
>verify the signature, the old certificate to bind that key to identity, as 
>long as there is proof of validity at the time in the past (archived OCSP 
>response for example)? Perhaps this use case raises an additional requirement:

See XAdES or RFC 3126.  It's pretty confusing, I can't keep it straight either.


>"For long term signatures the server must retain all signatures and 
>associated credentials as well as maintaining credential histories." - (I 
>note that we do not have server requirements so far, just representation 
>and protocol requirements.)

Yeah, I think we should stick to protocol requirements.



>---
>3.1.1
>In addition to XML time stamp token and Requestor identity element, we 
>might want an additional
>"Generic Signature Properties" work item with optional components 
>determined to be of value.

If we think of anything else, we could always add it to Core Elements.


>I would prefer to call "Requestor identity element" "Requestor Identity 
>Confirmation Element" since it confirms that the requestor identity is as 
>expected.

I don't see that - this element *tells* the relying party who the requestor 
was, it doesn't confirm anything he already knew.


>---
>3.1.2
>
>Should we limit the initial Binding focus to HTTP/SOAP and say this?

Fine by me, if people agree.

Do we want to commit to WSDL, also?  People have mentioned this a number of 
times, but I don't recall a discussion.



>---
>3.2
>"The Signing Protocol takes as input documents optionally with transforms 
>or document hashes, and creates a signature."
>
>I think we should clearly say "XML Signature" in this introduction, and I 
>note that XML Sig can handle a variety of signature algorithms. I propose 
>the following text:
>
>Although our focus is on XML Signatures, the intent is to define protocols 
>and mechanisms that can be extended to other types of cryptographic 
>signature representations such as CMS. In addition, various cryptographic 
>signing mechanisms are to supported, as XML Signature allows, including 
>public key based signatures as well as symmetric key MACs. We also 
>consider applications of signing that deserve special mention such as 
>Timestamps that require additional information to be included as signature 
>properties (e.g. RFC 3161 timestamp token).
>
>----
>3.2.1
>I suggest we remove the bullet "Extensible to others" since binary and XML 
>pretty much covers it.

I'll do that, unless people disagree.



>----
>3.2.2
>Rephrase to be more positive about XML Sig
>
>"XML Signature is an extensible and flexible mechanism that is compatible 
>with XML applications supporting advanced features such as transforms, 
>multiple references, sectional signing, and the ability to combine 
>signatures with XML content or to provide detached signatures.

I just stripped out a bunch of tutorial text.  Can't we assume the readers 
(i.e. us) know what XML-DSIG is?  I think the only important point there 
was that DSIG is more general than other formats, so that by targeting it, 
we'll basically cover their requirements without trying.


>In addition, the protocol design may be generalized to allow other formats 
>such as CMS or OpenPGP to support a wider range of applications."
>
>---
>3.3.2
>This section should be renamed "Requestor Confirmation", it is more than a 
>name, but the powerful concept of defining how the requestor has been 
>identified satisfactorily.

I don't see how this is a confirmation, and we've been using Requestor 
Identity ever since the use case was proposed, so I'd prefer to stick with 
it.  What do other people think?



>Add a bullet "Confirmation method" (much like SAML confirmation method if 
>we want bind the requestor identity to the request)

We'd be re-inventing SAML.  Why can't you just *use* a SAML Assertion if 
you want that feature?



>I think having a bullet for optional "Authentication Context" is useful, 
>specifically the Liberty definition. That covers a lot of ground that can 
>be reused as I mentioned before.

It fits into the 2nd bullet, as one of many ways a name can be 
supplemented.  Is that good enough?


>-----
>3.4.1
>
>Maybe we should change the bullet "ID references need special support" to 
>be "Mechanisms to support ds:References to elements without requiring 
>schema access are required."
>
>Can we say that schemas should not be required when referenced XML is in 
>canonical form and well known identifier attributes are used? (e.g. wsu:Id 
>attributes or saml:AssertionIds?) Mention of the SOAP Message Security 
>SecurityTokenReference transform might be appropriate (this transform says 
>don't hash what is referenced, but dereference that and then hash)
>----
>3.5.2 Signature placement
>
>We should mention detached signatures as an option.

Okay.



>----
>3.5.3 Output delivery
>
>We may have to define an XML element/multipart-mime/zip mechanism to 
>package output, especially if a signature is detached and references 
>multiple documents, such as for example an HTML page and 2 images 
>referenced from the HTML. Receiving the document back means receiving 
>three documents + a detached signature.

The signature will only ever be in one document, even if it covers multiple 
documents.  So do you really want the server to return those other 
documents, even though they're unchanged?


>  We could decide to stay with simple enveloped XML signatures for XML 
> content but eventually the issue of conveying multiple components will come up.

Does 3.4.1 cover this?



>----
>3.5.4 Intended audience
>
>I assume this is just meta-information included in the signature to list 
>who the intended audience is (limit liability). Like the SAML 
>AudienceRestrictionCondition.

No.  All the things in 3.5. are part of the Signing Request protocol 
message, they don't go in the signature.



>The reason I mention it, is that this is not a means to restrict viewing 
>by other audiences (i.e a confidentiality requirement) because we have no 
>intention of supporting XML Encryption with the developed services 
>(despite some potential commonalities)

No - it's just something the server can use to determine the various 
"Implicit Parameters" (see 3.5.6), such as what key to sign with.


>----
>3.5.5
>[326] "Requestor may provide additional attributes or request additional 
>server attributes be included in Signature Properties.

What if I change current text to "provide", not "request"?  As far as 
requesting attributes, could we say that's covered by 3.5.6 Implicit 
Parameters, bullet 4?


>----
>3.6.1
>We should mention possibility to return URL or reference # to retrieve 
>signature, either from URL or from signing server (respectively)

That was initially in the document and removed, since people found it 
unnecessary.



>----
>3.7.1 Selective Verification
>
>[366] Don't the XML DigSig processing rules require both signature 
>validation and SignedInfo reference validation (hash generation and 
>comparison), with the optional Manifest providing a way out? Why is this 
>listed as optional here?

The client may perform reference validation of some of the references 
himself, perhaps.


>  We need to be clear that we support both SignedInfo and Manifest 
> ds:References, but obey the DSig SignedInfo processing rules.
>
>----
>3.7.2 Verification time
>
>Should add the following:
>
>"This is possible only if the credentials for that time are either 
>presented in the request with supporting validation information (e.g. OCSP 
>responses) or have been stored at the server earlier."

I don't think that's correct.  What's to stop the server from going and 
getting an old CRL and checking against that, or delegating the query to 
some other DSS server, or using a protocol like SCVP to validate the cert 
chain at some time in the past?  I think we should just be concerned with 
protocol details, and not worry about how the server accomplishes the 
requests.



>----
>3.7.4
>
>We mention policy a lot and that can mean different things. Do we mean a 
>URI and the rest is out of scope,

We now have "Implicit Parameters" (3.5.6 and 3.7.8), which are things that 
are selected just by which URI you access.  We aren't calling these things 
policies anymore, cause that was confusing.

3.7.4 is talking only about the SignaturePolicyIdentifier of XAdES or 
equivalent - 3.7.4 is about the server parsing things out of the signature 
and then handing them to the client, to make the client's job easier, and 
that's one of the things the server could parse out.


>  or do we plan to define rule mechanisms or other ways of stating policy? 
> What is the representation of policy.
>
>---
>3.7.7
>
>Is the request for specific signature verification steps a request to use 
>a specific verification policy?

No.  It's a request to receive a purely informational list of what steps 
the server took in verifying the signature, ie:
<steps>
   <step>checkedSignature</step>
   <step>validatedPath</step>
   <step>checkedCRLs</step>
</step>

I'll add text to clarify.



>In general will we support policy both implicitly (URI defined as policy) 
>and explicitly (say the confirmation steps desired)?

I would prefer not to say "URI defined as policy", but to say "Implicit 
parameters", cause the word policy gets too overloaded.


>----
>3.9 Binding requirements
>
>Add a requirement to address replay and man-in-the-middle attacks.

Okay.


>----
>
>We may be missing one requirement that could impact the protocol.  To 
>satisfy "what you see is what you sign" we may need a 2 round-trip 
>protocol, a "Signing Confirmation", as follows:
>
>1. Request to sign something viewed involving underlying XML along with 
>XSLT transform (e.g. want to sign what is seen)
>2. Server signs a) XML b) XSLT (neither was seen)
>3. Server applies XSLT to XML returns to client
>4. Client displays verifies it is what they saw, confirming correctness of 
>mapping to XML+XSLT.

3.7.5 allows the client to request, on a Verification request, that the 
server should return the transformed data.  Do we want to add something 
like that onto the Sign protocol too?

Trevor