OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] [OASIS Issue Tracker] Commented: (OFFICE-3028) Updatedigital signatures for better XaDeS support


David,

David LeBlanc wrote:
> Inline -
> 
> Michael Brauer commented on OFFICE-3028:
> ----------------------------------------
> 
>> Regarding the changes for part 3:
> 
>> It adds:
> "A full document signature shall be stored in a file called META-INF/documentsignatures.xml, as described in part 1, section 3.16."
> 
>> We have already defined document signatures in part 1. There is no need to mention them here again in a normative way. But we may add a reference to part 1 as note, if that appears helpful.
> 
> IIRC, there was already redundant (and partially conflicting) information. I was trying to align the two sections.

Part 3 didn't mention document signatures at all, so I don't think where 
were conflicts. But I'm fine with mentioning document signatures in part 
3 as a note. We only should not mention them two times in a normative way.

> 
>> However, there seems to be a conflict with the changes proposed to part 1, which would turn a document signature into a possible partial signature.
> 
>> There is a change to
> 
>> In particular, consumers may require that a digital signature references all files contained in a package, *excepting the META-INF/documentsignatures.xml file, which cannot be included because a signature cannot sign itself.*"
> 
>> This statement seems to be wrong. A Reference element can reference the signature document itself. Using transforms one can exclude the DigestValue and SignatureValue.  Signing the signature documents prevents adding additional Object elements.
> 
> It is not a good thing to allow arbitrary XPath transforms, and definitely not a good thing to allow xlst transforms. You can get into some very nasty problems that way with phoning home and infinite recursion. Doing this also completely breaks XAdES, which is meant to allow changes to the UnsignedProperties element. As I indicated in my last mail, there are ways to accomplish this without signing the file containing the signatures. You could, for example, have one Signature element contain a Reference to a previously applied Signature element.

That may be true, but is this a justification for not allowing to 
include the signature file itself? If we want to disallow XPath 
transformation, when we should says so, etc.

> 
>> There are a lot of new clauses for <ds:Signature>, starting with:
> 
>> "A producer may use the XAdES extensions as specified in ETSI TS 101 903 v1.3.2 [XAdES], or later versions of the XAdES specification. Each <ds:Signature> element shall contain an Id attribute specifying a unique value."
> 
>> It is unclear to me whether these are intended to related to XAdes signatures only, or apply to other types of signatures, too. If they apply to XAdes signatures only, we should make this clearer.
> 
> This is good feedback - the second sentence and the first are unrelated. Thanks for catching this ambiguity.

Okay. Can you update the proposal so that it gets clear what is related 
to XAdes and what is not? My remark actually did apply also to the 
paragraphs that follow. Are these applicable to XAdes signatures only, 
and in general?

> 
>> If they apply to all kind of signatures, then there are a few statements that need further discussions. These are:
>> "A <ds:KeyInfo> element, as specified in [xmldsig-core], section 4.4 shall be included. The <ds:KeyInfo> element shall contain an <ds:X509Data> [...]"
> 
>> This restricts the permitted algorithms. Is this intended? Or does this only describe the Xades case?
> 
> I do not think this actually restricts the algorithms. Why do you say that this affects the choice of algorithms? It does imply you have an X509 certificate. The intent here is to make the existing implementation a defined part of the standard, which makes interoperability much easier.

It improves interoperability, but it may also forbid certain kind of 
signatures.

Do we know that this requirements works in all countries? What I would 
like to avoid are comments like "ODF's signature feature does not meet 
the requirements of country XYZ because it requires X509 certificates.

If the clause is about interoperability, then we may say something like:

Package consumers that support signatures shall/should support the 
<ds:X509Data> element.

This ensures interoperability if X509 certificates are used, but doesn't 
exclude other options.

> 
>> "The additional certificates should represent the entire primary certificate chain used at signing time."
> 
>> The term "primary" is used without explaining it. Different products used or use different path building algorithms  which may result in different "preferred path" in the same scenario. If XAded defines the term "primary", and if that clause shall related to XAded only, the language may be okay.
> 
> This is also not related to XAdES, and is just a problem with the way that PKI works. The definition of 'primary' chain is quite lengthy. If you can suggest a better way of expressing which certificates should be included, then we should change that. I think XAdES may have some language around this problem that we can re-use.

Well, unfortunately I'm not really a signature expert, so I don't have 
an alternative wording. My feedback is actually based on comments I've 
got from colleagues that are experts in that matter, and they told me 
that using the term "primary certificate chain" without explaining what 
it is may be problematic.

> 
>> "A <ds:Reference> element which refers to a file contained within the package shall have a Type attribute with a value of "http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.html".";
> 
>> Where does this type attribute come from?
> 
> I made it up (excepting that Reference elements do allow a type attribute). We need a way to specify Reference elements that refer to something in the package.
> 
>> Why is it containing 1.1 rather than 1.2
> 
> I made a mistake. It is a typo, and should have been 1.2.
> 
>> and why does it reference an HTML file (our authoritative files are the ODF files)
> 
> It was the best reference I could find, and if there is a better one, then we should use that. We really need to distinguish a Reference to the package from other types in an unambiguous manner, and XAdES does something similar to specify the XAdES signed information reference, so it seemed like a good approach.
> 
>> "A <ds:Reference> element with a Type attribute value other than those specified previously should be considered to be external to the package."
> 
>> What are external elements in an ODF document good for. It should not be a container for arbitrary stuff. What is the exact use of these types?
> 
> Frankly, not much. But the XmlDSig and XPath standards allow this, and so we should not disallow it. I don't see any real need to use it myself, but I want to be careful not to redefine other standards.

Okay. But then, shouldn't we then not also allow arbitrary XPaths and 
tranbformation?

> 
>> "Any <ds:Reference> elements contained within a <ds:Manifest> element, which is in turn contained within a <ds:Object> element, shall be considered to be implementation specific."
> 
>> This is basically what the XML Signature spec says and therefore seems to be redundant.
> 
> It is, but it seemed helpful to point out. We can certainly remove that sentence if there are objections.
> 
>> "The only permitted <ds:Transform> elements which apply to files contained within the archive shall be canonicalization transforms, as specified in [xmldsig-core], section 6.5."
> 
>> Why restricting the transforms? Xpath transform would be necessary  for signing parts of a document.
> 
> Because I know of serious problems that happen if you do not make this restriction. In particular, a signature could go recursive, resulting in a mild DoS attack against the consumer, and severe headaches for implementers who may try to prevent this. As a potential implementer, I have enough headaches.

Well, this is certainly correct, but the question is: Is this something 
that should be resolved in the ODF specification? I mean, we are using 
W3c Signatures, and the problem applies to W3C signatures. So, I would 
assume that there is advice for this by the W3C already.
> 
>> "The signing time shall be recorded using one or more of the following approaches:
> 1.An <ds:Object > element containing a <ds:SignatureProperty> element with:"
> 
>> I would not make signing mandatory in cases when the time was not obtained from a trusted source. That is, the time was not supplied by a "Time-Stamping-Authority". This excludes case 1. As for XadES, I would require validation data for the time stamp.
> 
> This was also attempting to standardize the existing implementation. It is fine with me if the signing time is not mandatory, but I know I have places in my code where I emit some element, and then have an improper assumption that others emit it as well. If we all agree to put the same elements, then it helps interoperability. However, IIRC, the untrusted signing time is a required XAdES element for the lowest levels of XAdES. The timestamp time could well be days or even weeks later. I think it is fine to have an untrusted signing time as long as you treat it as untrusted.

Again, I think this is more the question of shall vs. should and what 
are requirements for XAdes, and what are requirements for signatures in 
general.
> 
> Thanks very much for the detailed feedback.

You are welcome. Can you refine your proposal based in the feedback you 
got? That would be very helpful.

Thank you.

Michael


> 
>> Update digital signatures for better XaDeS support
>> --------------------------------------------------
>>
>>                 Key: OFFICE-3028
>>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3028
>>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>>          Issue Type: Improvement
>>          Components: Part 1 (Schema), Part 3 (Packages), Public Review, Security
>>    Affects Versions: ODF 1.2 CD 05
>>            Reporter: Cherie Ekholm
>>            Assignee: David LeBlanc
>>             Fix For: ODF 1.2 CD 06
>>
>>
>> David LeBlanc's proposal for updating digital signature support:
>> A summary of the changes:
>> Part 1, section 3.16:
>> Modified to read:
>> An OpenDocument document that is stored in a package may have one or more digital signatures applied to the package.
>> Document signatures shall be stored in a file called META-INF/documentsignatures.xml in the package as described in section 2.4 of the OpenDocument specification part 3.
>> A document signature shall be considered to be valid only if the "XML Digital Signature" contained in documentsignatures.xml is valid.
>> Document signatures shall contain a <ds:Reference> element for each file within the package, with the exception that a <ds:Reference> element for the file containing the signature is omitted. If non-standard files are added to the package, then it is implementation-specific whether <ds:Reference> elements for the additional files shall be required. An implementer may also choose to support a partial document signature which may contain <ds:Reference> elements for only some of the files within the package or portions of files.
>> Part 3:
>> Addition of xades to the namespace table Packages, Digital Signatures
>> section:
>> Added "A full document signature shall be stored in a file called META-INF/documentsignatures.xml, as described in part 1, section 3.16." to be consistent with part 1.
>> <dsig:document-signatures> section:
>> Changed:
>> In particular, consumers may require that a digital signature references all files contained in a package.
>> To:
>> In particular, consumers may require that a digital signature references all files contained in a package, excepting the META-INF/documentsignatures.xml file, which cannot be included because a signature cannot sign itself.
>> I didn't touch the next 2 paragraphs, but these are a problem due to the encryption conundrum.
>> <ds:Signature> section:
>> This is long, and I'll wait for Cherie here. Basically, it puts into standards language the what I suggested in e-mail previously, and specifies the current signature implementation of (IIRC) Open Office as the standard, and adds in the information needed to do XAdES such that everyone can interoperate.
>> Copied from David's editted document, the section would read:
>> The <ds:Signature> element is defined by the [xmldsig-core] specification. A producer may use the XAdES extensions as specified in ETSI TS 101 903 v1.3.2 [XAdES], or later versions of the XAdES specification. Each <ds:Signature> element shall contain an Id attribute specifying a unique value.
>> A <ds:KeyInfo> element, as specified in [xmldsig-core], section 4.4 shall be included. The <ds:KeyInfo> element shall contain an <ds:X509Data> element containing at least an <ds:X509IssuerSerial> element specifying the issuer and serial number of the signing certificate, and an <ds:X509Certificate> element specifying the full signing certificate. Additional <ds:X509Certificate> elements may be placed in the <ds:X509Data>, or may be placed in the <xades:CertificateValues> element of the XAdES <ds:Object>, as defined in [XAdES] section 7.6.1. The additional certificates should represent the entire primary certificate chain used at signing time.
>> <ds:Reference> elements contained within a <ds:SignedInfo> element shall be resolved according to the following specification:
>> 1.    A <ds:Reference> element which refers to a file contained within the package shall have a Type attribute with a value of "http://docs.oasis-open.org/office/v1.1/OS/OpenDocument-v1.1.html";. The <ds:Reference> URI for files contained within the package shall be Relative IRI references contained within the element or any of its descendant elements shall be resolved as defined in section 3.7, except that the base URI for resolving relative IRIs shall be the package base IRI.
>> 2.    A <ds:Reference> to an <ds:Object> element contained within this <ds:Signature> element shall have a Type attribute with a value of "http://www.w3.org/2000/09/xmldsig#Object";. The <ds:Reference> URI for an <ds:Object> element shall be considered to be relative to the <ds:Signature> element.
>> 3.    A <ds:Reference> element which refers to the XAdES SignedProperties element (if present) shall be as specified in [XAdES] section 6.3.1.
>> 4.    A <ds:Reference> element with a Type attribute value other than those specified previously should be considered to be external to the package.
>> Any <ds:Reference> elements contained within a <ds:Manifest> element, which is in turn contained within a <ds:Object> element, shall be considered to be implementation specific.
>> The only permitted <ds:Transform> elements which apply to files contained within the archive shall be canonicalization transforms, as specified in [xmldsig-core], section 6.5.
>> The signing time shall be recorded using one or more of the following approaches:
>> 1.    An <ds:Object > element containing a <ds:SignatureProperty> element with:
>> a.    An Id attribute with a value containing a unique identifier.
>> b.    A Target attribute corresponding to the Id attribute of the <ds:Signature> element.
>> c.    A <date> element from the namespace "http://purl.org/dc/elements/1.1/"; containing the time in UTC format.
>> 2.    A <xades:SigningTime> element as specified in [XAdES] section 7.2.1.
>> If an <ds:Object> containing XAdES elements is present, then a document compliant with this specification uses the following options:
>> 1.    The <xades:SignedSignatureProperties> element shall contain a <xades:SigningCertificate> property as specified in [XAdES] section 7.2.2.
>> 2.    A <xades:SigningTime> element shall be present as specified in [XAdES] section 7.2.1.
>> 3.    ) If any timestamp elements of type XAdESTimeStampType are present, such as the <xades:SignatureTimeStamp> or <xades: SigAndRefsTimestamp> elements, the time stamp information shall be specified as an EncapsulatedTimeStamp element containing DER encoded ASN.1. data.
>> 4.    ) If references to validation data are present, the <xades:SigAndRefsTimestamp> element as specified in [XAdES] sections 7.5.1 and 7.5.1.1 shall be used.
>> 5.    There shall be a <ds:Reference> element specifying the digest of the SignedProperties element, as specified in [XAdES], section 6.2.1. This <ds:Reference> element shall be contained within the <ds:SignedInfo> element of the <ds:Signature> element.
>> Oh - as I was reviewing this, I noticed that I forgot to add language to support the XAdES CounterSignature element, which itself contains one or more Signatures, each of which may also have a CounterSignature. We need to make sure that restrictions on the <ds:Signature> element do not preclude using them differently in a CounterSignature.
> 
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 


-- 
Michael Brauer | Oracle Office Development
Phone: +49 40 23646 500
Oracle Office GBU

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Rijnzathe 6, 3454PV De Meern, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]