Re: xmldsig questions

At 16:29 99/12/14 -0500, Frederick Hirsch wrote:
 >I have some questions on the XML-Signature core syntax and processing
 >document

I'll answer what I can, but I think the other authors could address much of
this better than me.

 >I have some questions about signed XML, specifically regarding 
 >Draft 07-December-1999,  
 >http://www.w3.org/Signature/Drafts/WD-xmldsig-core-19991207.html

 >1. If I wish to not include the OBJECT elements themselves in the
signature for
 >the transaction, is the example xpath transform below correct? If so, what
 >does the draft mean in section 5.6.3 (Xpath filtering) that the root
 >should be included so the result is well-formed? I thought I only want
 >to sign the contents of the referenced object element. Is there an
 >example available?

In your example, I believe your XPath would grab <txn xmlns=...> which is
the root of that object. You could also give the txn element type an ID and
reference that directly without using the XPath.

 >2. For KeyInfo, KeyData, Is it correct to assume a CERTIFICATE element
 >for each certificate in the signing party certificate chain? Is it
 >correct to specify the encoding for each as an attribute of the
 >certificate element?  

David, Barbara, others?

 >I am assuming that each certificate is base64 encoded (encoding type)
 >of the DER encoding.

Yes.

 >3. I assume that X.509 oids are not used since they are implicit in an
 >XML element. Thus for example, if the signer sends device specific
 >information as part of signing, the OID for this information would be
 >implicit. Thus if in ASN.1 it is AUTHINFO and an OID, the tag
 >SignerDeviceInfo would be enough - if the recipient knows to map this
 >to the OID. (I guess I'm asking and assuming OID mapping is
 >application dependent). 

David, Barbara, others?

 >4. In section 3.4, KeyInfo, I note that the spec allows including a
 >CRL, with element X509CRL. Can we also define including signed OCSP
 >responses, with an X509OCSP element? This would allow transmitted the
 >status of the certs with a transaction in an interoperable manner. 
 
David, Barbara, others?

 >5. What is the relationship between SignatureAttribute object types
 >and SignatureProperties elements, and when is either necessary?
 >
 >How is the optional type in an ObjectReference element used?
 >(section 3.3.3). Does it matter if I have it or not? It seems not to
 >matter. (e.g. <Object ID="timestamp"
 >	      type="&dsig;/SignatureAttributes">
 >vs <Object ID="txn">

I don't think it matters nor is necessary, but if an application wants to
use it, they could as you have. David?

 >Should all signature attribute objects be within SignatureProperties
 >elements? I'm a little confused because it looks like properties of
 >the signature (e.g. signing time) belong in SignatureProperties, but
 >that is not how example 8.0 works. Is there a guideline?
 
You are correct there is an conceptual inconsistency in the example.
SignatureProperties should only be used for things about the signature, but
we don't specify that all things about a signature must appear in
SignatureProperties. I will tweak that example to use them.

 >6. Likewise in the ObjectReference section 3.3.3, I'm not clear what a
 >"parent document" is when using the null URL. Does this mean the root
 >of the current document or something else?
 
Yes, the root of the current document, I will make sure we are consistent.

 >7. The difference between SignedInfo, Manifest and Package is (to restate)
 >SignedInfo - each digest must be validated
 >Manifest - each digest may be validated
 >Package - each referenced object should be the same after transforms
 >are applied (e.g. this is like mirrors for the reference info)
 
Yes.

 >A package may be used as a Object reference within a SignedInfo or
 >Manifest, but then  only the digest of the manifest (and not the
 >content itself is signed. 
 
Yes.

 >8. I might suggest adding in the security section (section 7), that in
 >the X.509 case, the security also depends on the validity of the signers
 >certificate chain, and that if any private key has been compromised the
 >document signature is not dependable, so signature validation may only
 >be the first step in a process to reduce the risk of depending on the
document.
 
I hope this is clear given the distinction in the definitions between
signature, core, and application validation in the latest draft.

 >9. Section 1.3 refers to the XML namespace xmldsig-core, but the other
 >namespaces (e.g. SHA1) include dsig-core. Are they intentionally different?
 
Well, given they have the same prefix, they are supposed to be seen as part
of the larger namespace. Given that XML-ns don't ascribe any semantics to
the URI, this is our own convention... One could use fragment identifiers
like RDF:

        .../xmldsig-core#sha-1

but I think they ran into some problems with that. Would you suggest
something different?


_________________________________________________________
Joseph Reagle Jr.   
Policy Analyst           mailto:reagle@w3.org
XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 20 December 1999 18:40:04 UTC