XAdES elements in OFF-CRYPTO of Microsoft

[MURATA Makoto]

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/20150124/eea0d753/attachment-0001.html>