Re: [widgets] Digital Signatures

Hi Thomas,

On Fri, Apr 4, 2008 at 11:30 PM, Thomas Roessler <tlr@w3.org> wrote:
> Hi Marcos,
>
>  some observations while going through the document...
>
>  - Introduction: signing doen't necessarily involve encrypting a hash
>   value, so don't say it does.  (E.g., you could cast an RSA
>   signature into an encryption / decryption process, but you can't
>   do that with a DSA signature.)

Text now reads:

"Digitally signing a widget resource involves signing all of its file
entries using a unique private key that is known only to the signer.
The resulting encrypted signature, along with the signer's digital
certificate, is structured into an XML document, and included at the
root of a widget resource under the name signature.xml."

>  - What does "hashing the directories" mean?

Nothing.  All file entries are treated equally.

>  - Signature profile: "All resources must be  ... included with the
>   signature.xml file" -- does that mean that all resources are
>   enveloped within the signature?  I suspect you mean that all
>   resources must be signed.  Say that.

Ok, says that now:
"Every file entry in a widget resource must be signed. The resulting
digital signature must be serialized into an UTF-8 encoded XML
document and placed at the root of the widget archive under the name
signature.xml."

>  - You write: "All digests must be calculated using RSA-SHA1".  You
>   prbably mean that the signature is calculated using RSA-SHA1, and
>   that the individual Reference elements will use SHA1 as the digest
>   mechanism.  Note that it is possible to use RSA-SHA1 as the
>   SignatureMethod, and a hash algorithm different from SHA1 for a
>   reference element.

Yep, my bad. Changed it to:
"2. Reference elements must use the SHA1 as the digest method.
 3. The signature method to produce the SignatureValue must be RSA-SHA1."

>
>  - You might want to actually force a SignatureProperties element to
>   be present, to identify the version of the profile that's used by
>   a given signature.

What would this look like?

>  - Conformance: You say that the only product class that can claim
>   performance is a digital signature document; yet, a bit later, you
>   claim that "a widget user agent must behave as described by this
>   specification."  There's a bit of inconsistency here.

Added Widget User Agent as a class of product.

>  - I don't understand the deflate transform.  Do you assume (for the
>   example) that a file index.html is part of the widget resource,
>   but actually holds compressed content that needs to be deflated,
>   in addition to any unpacking of an outer packaging layer that
>   would hold signature.xml and index.html?

I will remove it.

>   Also, note that signing the deflated content means that conforming
>   user agents would have to perform an additional deflation step,
>   possibly leading to additional attack surface.

Yeah, it's a risk. Signing now happens on the raw data found in a file
entry's data field, regardless of it being compressed or not.

>   (I suspect that the idea is that the URI parameter is input to a
>   Zip extractor, and that extractor is identified as a transform.

Yes.

>   That actually doesn't fit well into xmldsig-core's reference
>   processing and transform model, as that model means that you
>   dereference the URI and then pass the information retrieved into
>   the transform chain.

Yeah, I tried to do this with the Java implementation and got stuck.
That's why I thought the Deflate Transform might solve the problem...
guess not.

>I'd suggest that, instead, you say how
>   relative URI references within a signature that conforms to this
>   profile are interpreted.)

I've added a note that says: "ISSUE: path must be checked and
normalized to a valid uri for this specification."

In the verification process, I've said:
"Apply the Reference Validation algorithm as defined in [XMLDsig], by
taking each Reference element and exactly matching the value of the
URI attribute to the file name field of a file entry. Validate against
the matched file entry's data field (do not use the decompressed
representation)."

So, no extraction is done and matching of the URI must be exact to
something in the Zip file ( /config.xml !=  "/test/../config.xml")

>  - Section 5 sounds like it has a user agent as the conforming
>   product, not a document.  That said, I suspect that this section
>   basically says "for each file in the widget, generate a Reference
>   element that holds a digest of that file."  That's unnecessarily
>   obscured by the detailed step-by-step instructions for creating
>   the document.
>
>   -1 to writing pseudocode here.

I agree, I'll change the pseudocode later. The pseudocode makes it
easier (for me) to work out the logic at this point...  (though I am
not claiming it has helped!;)).

>  - Why use ds:Manifest?  Thats for holding ds:Reference elements that
>   you don't necessarily want to dereference, e.g., because you've
>   several signatures for the same URI reference (signing multiple
>   representations), or because you've signature semantics that make
>   verifying signatures on certain resources optional.  I don't think
>   that's the case here.

You are right. I had misunderstood the function of manifest. Manifest
is gone. Everything is in Signed info now.

>   On the other hand, if you just use a collection ds:Reference
>   elements which are direct children of ds:SignedInfo, XML Signature
>   core validation will ensure that all resources are signed.

Yes. This is what we want: core validation on the entries.

>  - In the verification procedure, you say:
>
>      1.  If the widget user agent does not contain the root
>      certificate that allows it to verify the <KeyInfo> certificate,
>      then the widget user agent should warn the user that the
>      certificate is not trusted.
>
>   What does "contain" mean here?  Is a certificate "contained" when
>   it's on a list of explicitly untrusted root certificates?  Is the
>   certificate to be trusted when the user agent has the root
>   certificate's hash stored somewhere, but the certificate is only
>   included with KeyInfo?
>
>   Please be precise about what you mean here.  Also, I'd rather say
>   that the signature MUST be considered invalid than go into
>   detailed UA behavior (for the purposes of this particular
>   specification, at least).

I've said this:
"If the widget user agent cannot verify the certificate from its list
of explicitly trusted root certificates, then the certificate must be
treated as invalid."

Hopefully that is good enough for the FPWD.

Kind regards,
Marcos
-- 
Marcos Caceres
http://datadriven.com.au

Received on Tuesday, 8 April 2008 06:32:36 UTC