OASIS Open Document Format for Office Applications (OpenDocument) TC

 View Only
Expand all | Collapse all

DSIG proposal - FYI

Bob Jolliffe

Bob Jolliffe01-05-2009 13:27

  • 1.  DSIG proposal - FYI

    Posted 12-12-2008 09:09
    Greetings

    For those who are busy examining proposals I'd like to point out that, in the interest of progress on 1.2, I have drastically simplified the digital signature proposal made earlier this year by Jomar and myself.
     
    http://wiki.oasis-open.org/office/DSigProposal

    As it currently stands, there are no longer any schema changes being proposed - just a short (two sentence) addition to the text indicating that:

    "These digital signatures shall conform to the W3C XML Digital Signature specification (http://www.w3.org/TR/xmldsig-core/). Applications may use extensions to the XML DSIG core specification, such as those required for implementation of XAdES signatures specified in ETSI TS 101 903 v1.3.2."

    Regards
    Bob


  • 2.  RE: [office] DSIG proposal - FYI

    Posted 01-05-2009 07:00
    Bob, I want to support this proposal.  I have some questions and
    suggestions:
    
    1. Definitive References
       1.1 Please provide a definitive reference to ETSI TS 101 903 v1.3.2 that
    someone could use to obtain the specification.
       1.2 I suggest that that [xml-dsig] reference a specific version of the
    XML DSIG specification. Unless there is a conflict with ETSI TS 101 903, or
    with canonicalization of ODF XML items, I suggest "Donald Eastlake, Joseph
    Reagle, David Solo, Frederick Hirsch, Thomas Roessler (eds.).  XML Signature
    Syntax and Processing (Second Edition).  W3C Recommendation 10 June 2008.
    Available at 


  • 3.  Re: [office] DSIG proposal - FYI

    Posted 01-05-2009 13:27
    Hi Dennis
    
    2009/1/5 Dennis E. Hamilton 


  • 4.  Re: [office] DSIG proposal - FYI

    Posted 01-05-2009 14:43
    Hi,
    
    On 05.01.09 14:26, Bob Jolliffe wrote:
    
    >>  2.2 In the 


  • 5.  Re: [office] DSIG proposal - FYI

    Posted 01-05-2009 21:25
    Hi
    
    2009/1/5 Michael Brauer - Sun Germany - ham02 - Hamburg
    


  • 6.  RE: [office] DSIG proposal - URI vs.

    Posted 01-05-2009 23:03
    I don't think it is that hard to choose.  I agree that it is rather
    arbitrary which choice is made.
    
    Here's my thinking:
    
    1. [xml-dsig] specifies URI, so it seems rather difficult to borrow from
    that namespace and not use the same scheme.  We can't easily insert the
    package-root type with out major surgery on the xml-dsig schema to have an
    alternative to the 


  • 7.  Re: [office] DSIG proposal - URI vs.

    Posted 01-06-2009 12:55
    Hi Dennis
    
    2009/1/5 Dennis E. Hamilton 


  • 8.  Re: [office] DSIG proposal - URI vs.

    Posted 01-06-2009 13:49
    Bob, Dennis,
    
    On 06.01.09 13:54, Bob Jolliffe wrote:
    > Hi Dennis
    > 
    > 2009/1/5 Dennis E. Hamilton 


  • 9.  Re: [office] DSIG proposal - URI vs.

    Posted 01-06-2009 14:13
    Hi Michael
    
    2009/1/6 Michael Brauer - Sun Germany - ham02 - Hamburg
    


  • 10.  RE: [office] DSIG proposal - URI vs.

    Posted 01-06-2009 21:12
    Oh, I see.  OK, for me "the root of the package" is different than the
    location of the package, with respect to Base URL.  I have some angst about
    that.  (By major surgery I meant introducing something other than the URI
    type, such as the package-path type used in manifest.xml.)
    
    INCIDENTAL REMARK: Also, although it has not been addressed in the ODF
    specification, the URI specification points out that the different segments
    of a path may have quite different rules because they pertain to different
    means of resolution, and this is the kind of detail for an application of
    URI to deal with, as in the use of paths inside Zip files by ODF.  It is
    actually a little underspecified in 17.5 how the cases work within and
    wandering out of a Zip file (especially around what is the character set and
    encoding for within-Zip segments, etc.).  There are not actual
    sub-directories inside of a Zip file (although a mapping to sub-directories
    is the common implementation for import and extraction).  I take the
    description of treating the path as if the package were unzipped into a file
    system to be a metaphor and a logical requirement, not a literal one, since
    the Unzip might fail around character-set requirements and case-sensitivity
    in an actual file system and/or since the literal path might not work in the
    actual file system. 
    
    ON-TOPIC: But for the use of xml-dsig, I just think we need to get clear on
    what "/" and "." mean as the URI attribute value in a 


  • 11.  RE: [office] DSIG proposal - URI vs.

    Posted 01-06-2009 21:57
    On reflection, I realize that there are a couple of ways to anonymously
    refer to the package itself as an octet stream although it is definitely a
    special case:
    
    If "/" refers to the (hypothetical) directory in which the package content
    appears as a subdirectory, the canonicalization for message digest could be
    that the package itself is the octet-stream canonicalization.  This could be
    extended to any "subdirectory" within the package although proper definition
    is tricky.  (It has to be as if there was a Zip that contained only those
    items, I think, and there are some edge cases to nail down)  Whether we need
    to identify a canonicalization method for this is something that we can look
    at for later.  For now, I think the idea is to find an approach that does
    not preclude this future option.
    
    This does get into the problem of embedding a signature in compressed
    content, but there are already rules that should be adaptable provided that
    (1) any 


  • 12.  Re: [office] DSIG proposal - URI vs.

    Posted 01-07-2009 10:18
    Hi Dennis
    
    You are much too prolific for me to keep up.  But I'm trying ...
    
    2009/1/6 Dennis E. Hamilton 


  • 13.  RE: [office] DSIG proposal - URI vs.

    Posted 01-07-2009 20:22
    Bob,
    
    The key part of this note is in (3)-(4) below, where I am having second
    thoughts.  For completeness, there is more information on Zip specifications
    and what ODF does and does not seem to normatively include.  I should have
    put these sections in a different sequence, with the backup analysis below
    the fold.  I am out of time on this for now.  Sorry.
    
     - Dennis
    
    PS: If you want to confine the 


  • 14.  Re: [office] DSIG proposal - URI vs.

    Posted 01-07-2009 22:07
    Hello Dennis
    
    2009/1/7 Dennis E. Hamilton 


  • 15.  Res: Re: [office] DSIG proposal - URI vs.

    Posted 01-07-2009 22:41
    Just a note on Bob's (excellent) answer.
    
    We already approved the conformance clauses proposed by Michael an we have there some details about what 'application specific' means for ODF 1.2 documents (as far as I remember, the definition was Rob's suggestion made on November, 2008).
    
    Best,
    
    Jomar
    
    


  • 16.  RE: Re: [office] DSIG proposal - Application vs. Implementation re specifications

    Posted 01-07-2009 23:49
    Um, implementation-specific and application-specific are different for me.
    
    To be clear in this case, specifications such as the one for xml-dsig,
    xml-id, and also URI and IRI, provide for application-specific
    customizations and elaborations.  In this case, incorporation in the ODF
    specification is an *application* relative to those specifications.  ODF
    might provide for further application-specific (e.g., an industry-specific
    interoperability profile) and implementation-specific details as well.  My
    intention was to use application-specific in the sense that incorporation in
    ODF is an application of the other specification (not an implementation),
    and that profile details are important (especially in the application of URI
    segments to elements within a Zip file and generally in the reference to
    PKZip, which covers a lot of things that one hopes not to have to be deal
    with in ODF processor).  If I deviated from that objective, it was
    unintentional.
    
     - Dennis
    
    PS: I don't believe that the conformance clauses are approved at this point,
    but I don't think that matters to this discussion.
    
    


  • 17.  RE: Re: [office] DSIG proposal - Application vs. Implementation respecifications

    Posted 01-08-2009 16:28
    You start with the standard and the scope of the standard.  Behaviors are 
    either within scope of the standard, or not within scope.
    
    For items within scope of the standard you have the following kinds of 
    behaviors:
    
    Specified -- the things that the standard defines completely.
    
    Unspecified -- the things that the standard allows a conforming 
    application to implement as they please.
    
     Application-defined (synonymous with implementation-defined) -- 
    parameters of a standard that are defined and documented by the product 
    that conforms to the standard.  In other words, the standard does not 
    specify the behavior, but the implementation does. 
    
    Undefined -- Has a more negative meaning than Unspecified, for things like 
    division by zero, where we wish to indicate that reliance on specific 
    behavior for undefined features will result in non-portable use of ODF. 
    
    The use of in one standard of another standard as a whole, is just a 
    normative external reference.  But if you use another standard in part, or 
    with qualification, then the definition of how that other standard works 
    in your standard is a "profile" of the other standard.
    
    It would certainly be a good thing if, anywhere we we include a standard, 
    but with some qualification of it, that we consistently indicate how we 
    are profiling that other standard.
    
    -Rob
    
    _
    "Dennis E. Hamilton" 


  • 18.  RE: Re: [office] DSIG proposal - Application vs. Implementation re specifications

    Posted 01-08-2009 18:54
    For me, confusing application of an instrument and the implementation of
    that instrument impoverishes the language we require in order to be clear
    about standards for artifacts and behaviors realized with computer software.
    (I.e., the software is not the application of the user, it might be an
    implementation of a specification.  I notice that IP language refers to
    implementation of specifications too.)  And, fortunately, we don't have to
    align on that, although I am not sure what alternative terminology affords
    the distinctions I see and want to speak carefully about.  
    
    I am completely aligned with the importance of profiling a standard that is
    normatively incorporated by reference and where that standard has provisions
    for adaptation/customization in an application (the typical phrasing in the
    specifications I had been looking at).  I think a problem that we have in
    the current ODF specifications and heavy incorporation of other standards by
    reference is the omission of profiling and leaving qualifications to tacit
    assumption.
    
     - Dennis 
    
    


  • 19.  RE: [office] DSIG proposal - FYI - Root Element

    Posted 01-05-2009 18:29
    Bob, I misunderstood the FYI note about simplification of the ODF DSIG
    proposal.  
    
    I didn't realize the schema for 


  • 20.  RE: [office] DSIG proposal - FYI - Root Element - IMPORTANT!

    Posted 01-07-2009 21:35
    Woops, that's an OpenOffice.org-specific namespace that you mention as being
    in the package specification!  If that's the legacy implementation, I think
    we are excused out of the box with 
    
    


  • 21.  RE: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal

    Posted 01-08-2009 00:47
    I feel really thick-headed.  I wandered all over the place because of the
    "existing implementations" concern, when the answer is right in front of us.
    Here is my understanding of the appropriate resolution:
    
    1. The introduction of the ODF usage of xml-dsig will be via the proposed
    namespace and the xml-dsig namespace, as currently specified in the schemas
    for the DSIG proposal:
    
       1.1 The ODF 1.2 namespace for ODF DSIG will be
    "urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0".
    
       1.2 The xml-dsig namespace is "http://www.w3.org/2000/09/xmldsig#" 
    
       1.3 For example, the element introduced by the tag
    
       


  • 22.  RE: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION

    Posted 01-08-2009 02:01
    My (3) in the original note doesn't make sense because I didn't alter the
    namespace in the "e.g." phrase. 
    
    I have since confirmed, by generating some signed documents in OpenOffice
    2.4 and 3.0, that there are indeed documents in the wild that use the
    "urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0" namespace as
    well as  "http://openoffice.org/2004/documentsignatures" and in both cases
    the URIs look relative but are comparable to manifest:full-path values.
    [PS: With regard to recommendations about digest algorithms, I see only
    SHA-1 being used for digests here.  The signature itself uses PKI and, in
    the case of my certificate, SHA-1 is used as part of the PKCS #1 RSA
    Encryption.  I'm not worried.] 
    
    Therefore, here is my revised solution to the dilemma, with the namespace to
    be changed at once:
    
    1. The introduction of the ODF usage of xml-dsig will be via the proposed
    namespace and the xml-dsig namespace, to be revised in the schemas
    for the DSIG proposal:
    
       1.1 The ODF 1.2 namespace for ODF DSIG will be
    "urn:oasis:names:tc:office:xmlns:digitalsignature:1.0" 
    (or any other acceptable, normative URI other than
    "urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0").
    
       1.2 The xml-dsig namespace is "http://www.w3.org/2000/09/xmldsig#" 
    
       1.3 For example, the element introduced by the tag
    
     


  • 23.  Re: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION

    Posted 01-08-2009 10:01
    Hello Dennis
    
    First of all, well spotted on the namespace.  I hadn't noticed that
    OOo 3.0 had started using the new namespace..
    
    2009/1/8 Dennis E. Hamilton 


  • 24.  RE: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION

    Posted 01-08-2009 18:54
    Bob, I think the problem is that it conflicts with the obvious
    interpretation of the URL parameter when the expansion into a hypothetical
    directory hierarchy takes place, in contrast with the Package section 2.6
    rule which, under the stated 2.6 restraints, works the same either way
    (ignoring the corner cases involving character sets and encodings).
    
    In fact, if you simply said that the constraint on the xml-dsig 


  • 25.  Re: [office] DSIG proposal - URIs, Packages,and Namespaces - Proposal CORRECTION

    Posted 01-08-2009 19:59
    The Package section 2.6 is indeed mistakable. Of course should resources
    within the ODF package be referable from outside.
    The usability of that package would be poor if this is not possible.
    If someone annotates parts of the package (files, XML elements) with
    metadata, it is desirable to refer/point directly to them.
    
    Regards,
    Svante
    
    Dennis E. Hamilton wrote:
    > PS: Does anyone know if the metadata RDF proposal use of URIs also going to
    > be an exception to Package section 2.6?  Lets not do that for any of these
    > borrowed standards that use URI in widely understood ways and that we have
    > not explicitly constrained very well.  The saving grace for manifest.xml is
    > the use of an ODF-specific definition for the manifest:full-path attribute.
    >   
    >
    


  • 26.  RE: [office] DSIG proposal - URIs, Packages, and Namespaces - Proposal CORRECTION

    Posted 01-08-2009 22:49
    I don't understand this comment.  Are you saying that 2.6 is incorrect?  
    
    I agree that the statement about not being to refer into a package from
    outside is a mistake.  The ODF specification has no standing in saying what
    people can do from outside of an ODF package.  Based on our extensive
    experience with 17.5 in ODF 1.0/1.1, that claim should simply be removed.
    
    On the other hand, based on the same experience with 17.5, I believe the
    rules for URIs in ODF content within the package are intended: (1) URIs
    within a package can refer to material in the same package and outside of
    the package but (2) not back inside of a package from outside (the same one
    or another).  And (3) resolution of a relative-path URI is by interpreting
    the base URI to be the hypothetical location of the stream having the URI,
    as if the package were expanded in the usual way into a directory of a file
    system.
    
    Do you agree that those cases in 2.6 do apply to the metadata RDF contained
    within an ODF package?
    
     - Dennis
    
    


  • 27.  RE: [office] DSIG proposal - external-sigining use case

    Posted 01-09-2009 00:17
    Here's an use-case where signing material external to a document can matter.
    
    An ODF master document is an ODF document that includes other ODF documents
    as the contributions of parts to it.
    
    Clearly, the individual parts can be individually signed using DSIG.  They
    have independent existence as documents and that's just fine.  However, this
    does not account for their important use in combination with a given master
    document.
    
    There can also be external parts of any ODF document and these parts,
    whether signable or not, are not tied to any signature that is exclusively
    on the document that refers to the parts.
    
    The master document can be signed using DSIG, of course, and that can
    effectively sign the references to the parts but it doesn't do anything
    about tying the signature over the targets of the parts (which are
    presumably accessible and amenable to digesting as octet streams).
    
    The use case applies any time there is companion material that needs to be
    embraced by a single signature with the main document in order to assure
    that the composite is properly signed.
    
    Once could handle this with an external signature not involving ODF DSIG at
    all, and we could let it go at that.  Or we could simply not preclude the
    eventual natural extension of the rules to allow it through eventual
    relaxation of restrictions atop of the existing 2.6 provision.  (In other
    words, "never say never" as an architectural principle companion to "avoid
    irreversible decisions.")
    
     - Dennis
    
    PS: Even if what is signed in the master document is the (synthetic)
    document that is somehow the master with the components merged in, it would
    be pretty hairy to accomplish that with a canonicalization rule that doesn't
    invoke the specific parts somehow, since it is necessary to redo the
    canonicalization as part of verifying the signature.  Although there are
    principles in xml-dsig that might be honored better this way, this is far
    more difficult than simply referencing the components in the signature of
    the master document that is intended to embrace some or all of the external
    material.
    
    PPS: I have no idea what happens in signing a master document and its parts
    in the current implementations.  I also don't know what they have to say
    about the digital signatures when the master document is opened.  (OO.o 2.4
    allows signing of the parts but not the master document and it appears to
    make no note of the signing of the parts when the master document is opened
    with incorporation of the linked parts.  I am not that curious what OO.o 3.0
    does when in "ODF 1.2" mode.)
    
    PPPS: If we are going to talk about OOXML's restriction of references in
    signatures to parts of a package, which is indeed the case, we should note
    how they accomplish that using package-specific rules that carefully profile
    xml-dsig.  It is instructive to see how they did it without breaking
    explicit rules in xml-dsig.  I commend Section 13 of ISO/IEC 29500-2:2008 to
    your attention, along with the interesting example in subsection 13.3.  This
    specification sets a pretty high mark for precision and rigor that is to be
    aspired to but I believe is out of reach for ODF 1.2 for several reasons.  I
    also point out that the way package-specific URI rules are introduced is by
    use of manifests in 


  • 28.  Re: [office] DSIG proposal - external-sigining use case

    Posted 01-11-2009 22:49
    Hi Dennis
    
    It's an interesting use case.  There are perhaps even others.  One can
    imagine a scenario where a signature policy exists and is accessible
    via a http URI.  One might want include a reference to the external
    policy in the signed information so that a validator could assure
    itself that the policy being referenced is the same as that which was
    in force when the document was signed.  Whether it is a good idea to
    implement such schemes is another matter, but I agree we probably
    shouldn't preclude the possibility.
    
    Which of course currently we don't.  This will perhaps be one of the
    challenges to be addressed in the next version.
    
    I agree, and I've said on a few occasions before, that the OOXML part
    2 is a well crafted document.  As for the signature, I don't really
    like the approach of using an extra level of indirection to get to the
    actual content to be signed, but it works.  To me it feels like too
    much advantage is being taken of the generosity offered by the
    ds:Object element in xml-dsig.  But its a justifiable design decision
    and also probably a bit off topic to discuss here.
    
    Regards
    Bob
    
    2009/1/9 Dennis E. Hamilton 


  • 29.  RE: [office] DSIG proposal - definition of URL case

    Posted 01-12-2009 02:42
    Thanks Bob,
    
    Just for the record, is there any decision on exactly how the restriction on
    


  • 30.  Re: [office] DSIG proposal - definition of URL case

    Posted 01-12-2009 09:10
    Hi Dennis
    
    2009/1/12 Dennis E. Hamilton 


  • 31.  RE: [office] DSIG proposal - definition of URL case

    Posted 01-12-2009 16:26
    I meant the restriction that has it be interpreted as relative to the
    package root, not relative to the location Zip part that contains the DSIG. 
    
    


  • 32.  Re: [office] DSIG proposal - definition of URL case

    Posted 01-12-2009 09:38
    Dennis, Bob,
    
    here are couple of thoughts from my side regarding this topic.
    
    1. First of all, I think that the discussion what the base URI is for