XAdES elements in OFF-CRYPTO of Microsoft

[John Haug]

To be clear, MS-OFFCRYPTO is our documentation of how Office writes and reads digital signatures and in some cases includes information redundant to the standard to be explicit about what is in our files, so it oughtn’t be replicated verbatim in OPC.  I’ve also heard back on the items in MS-OFFCRYPTO we discussed in the January teleconference.  Comments on that and on Murata-san’s e-mail are covered here.


We are going to allow every level and recommend the use of A.
I agree we should allow every level, but I’m not certain about pushing -A, at least normatively.  I believe it’s been mentioned that sufficient infrastructure to support -A broadly is not really present yet.

> - A SigningTime element MUST be present as specified in [XAdES] section 7.2.1.
The second bullet is controversial.  Some believe that it is optional, while others believe that it is mandatory.  I think that we should simply reference XAdES without saying anything.
This is worth discussing.  Office writes it in OOXML files and requires it on read.  ODF recommends it (ODF 1.2 Part 3, subclause 5.3: “A <xades:SigningTime> element should be present as specified in [XAdES] section 7.2.1.”)

We only have to state that timestamps (if any) conform to RFC 3161.
Also worth discussing.  Is that the same as saying DER encoded ASN.1?  RFC 3161 does discuss ASN.1, but there are various methods of encoding data for ASN.1.  Both ODF (“the time stamp information shall be specified as an EncapsulatedTimeStamp element containing DER encoded ASN.1. Data”) and Office explicitly state DER encoded ASN.1.

This is merely a non-normative overview of C as specified in XAdES.  Delete it.
Agree, no need to include, adds no additional constraints.

This is merely a non-normative overview of X as specified in XAdES.  Delete it.
Agree, effectively.  As I speculated on the call, this requires use of XAdES-X type 1 when using XAdES-X (disallows type 2 – see Annex B.1 in XAdES 1.3.2) due to our early implementation of XAdES.  We don’t see any reason to preclude using XAdES-X type 2 in OPC.

This is merely a non-normative overview of X-Las specified in XAdES.  Delete it.
Agree, no need to include, adds no additional constraints.

The first and second bullets merely give nor-normative descriptions of XAdES and DSig, respectively.    Delete them.
Agree, no need to include, adds no additional constraints.

> A document compliant with this file format SHOULD<33> place the Reference element specifying the digest of the SignedProperties element within the SignedInfo element.
Again, this sentence is non-normative.  Delete it.
> If the Reference element is instead placed in a Manifest element, the containing Object element MUST have an id attribute set "idXAdESReferenceObject".to
This sentence is needed if we would like to explicitly allow the use of "idXAdESReferenceObject".  But we have agreed not to do so.
It does recommend using the SignedInfo option over the Manifest option (SHOULD is a normative term in our implementer notes docs because they follow RFC 2119).  From what our security contacts tell me, this is the more normal way to do things.  MS-OFFCRYPTO only lists the two and discusses the Manifest option because of an idiosyncrasy in Office 2007.  Office 2010 and 2013 use SignedInfo.  ODF requires use of the SignedInfo option.  I believe we should do the same.

John

From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: Friday, January 23, 2015 8:49 PM
To: SC34
Subject: Re: XAdES elements in OFF-CRYPTO of Microsoft

Dear colleagues,

Together with XAdES experts, the Japanese SC34 mirror studied MS-
OFFCRYPTO.  We believe that most of the quoted sentences are
not needed in OPC V2.

> 2.5.2.6 XAdES Elements
>
> XML Advanced Electronic Signatures [XAdES]
> extensions to xmldsig signatures MAY<32> be present
> in either binary or ECMA-376 documents [ECMA-376]
> when using xmldsig signatures.

This sentence explicitly allows the use of XAdES
in OPC.  Something similar is needed in OPC V2.

>XAdES-EPES through
> XAdES-X-L extensions are specified within a
> signature.

We are going to allow every level and
recommend the use of A.  So, this sentence
has to be changed.

>Unless otherwise specified, any optional
> elements as specified in [XAdES] are ignored.

This is harmful.  Even if some element is optional,
it has to be treated as specified in [XAdES].

> The
> Object element containing the information as
> specified in [XAdES] has a number of optional
> elements, and many of the elements have more than
> one method specified.

This sentence is just a non-normative
description of what is specified in XAdES.
Delete it.

>A document compliant with this
> file format uses the following options:
>
> - The SignedSignatureProperties element MUST contain
>   a SigningCertificate property as specified in
>   [XAdES] section 7.2.2.

> - A SigningTime element MUST be present as specified
>   in [XAdES] section 7.2.1.

The second bullet is controversial.  Some believe that it is optional,
while others believe that it is mandatory.  I think that we
should simply reference XAdES without saying anything.

> - A SignaturePolicyIdentifier element MUST be
>   present as specified in [XAdES] section 7.2.3.

At present, a SignaturePolicyIdentifier element
containing no policies are created by MS Office.
Miyachi-san believes that this is a bad practice
and OPC V2 should discourage such SignaturePolicyIdentifier

> - If the information as specified in [XAdES]
>   contains a time stamp as specified by the
>   requirements for XAdES-T, the time stamp
>   information MUST be specified as an
>   EncapsulatedTimeStamp element containing DER
>   encoded ASN.1. data.

We only have to state that timestamps (if any)
conform to RFC 3161.

> - If the information as specified in [XAdES]
>   contains references to validation data, the
>   certificates used in the certificate chain, except
>   for the signing certificate (1), MUST be contained
>   within the CompleteCertificateRefs element as
>   specified in [XAdES] section 7.4.1. In addition,
>   for the signature to be considered a well-formed
>   XAdES-C signature, a CompleteRevocationRefs
>   element MUST be present, as specified in [XAdES]
>   section 7.4.2.

This is merely a non-normative overview of C
as specified in XAdES.  Delete it.

> - If the information as specified in [XAdES]
>   contains time stamps on references to validation
>   data, the SigAndRefsTimestamp element as specified
>   in [XAdES] section 7.5.1 and [XAdES] section
>   7.5.1.1 MUST be used. The SigAndRefsTimestamp
>   element MUST specify the time stamp information as
>   an EncapsulatedTimeStamp element containing DER
>   encoded ASN.1. data.

This is merely a non-normative overview of X
as specified in XAdES.  Delete it.

> - If the information as specified in [XAdES]
>   contains properties for data validation values,
>   the CertificateValues and RevocationValues
>   elements MUST be constructed as specified in
>   [XAdES] section 7.6.1 and [XAdES] section
>   7.6.2. Except for the signing certificate (1), all
>   certificates used in the validation chain MUST be
>   entered into the CertificateValues element.

This is merely a non-normative overview of X-L
as specified in XAdES.  Delete it.

> There MUST be a Reference element specifying the
> digest of the SignedProperties element, as specified
> in [XAdES], section 6.2.1. A Reference element is
> placed in one of two parent elements, as specified
> in [XMLDSig]:
>
> - The SignedInfo element of the top-level Signature
>   XML.
>
> - A Manifest element contained within an Object
>   element.

The first and second bullets merely give nor-normative
descriptions of XAdES and DSig, respectively.    Delete
them.

> A document compliant with this file format
> SHOULD<33> place the Reference element specifying
> the digest of the SignedProperties element within
> the SignedInfo element.

Again, this sentence is non-normative.  Delete it.

> If the Reference element is
> instead placed in a Manifest element, the containing
> Object element MUST have an id attribute set "idXAdESReferenceObject".to

This sentence is needed if we would like to explicitly allow the use
of "idXAdESReferenceObject".  But we have agreed not
to do so.


Regards,

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20150207/07a8b887/attachment-0001.html>