XAdES elements in OFF-CRYPTO of Microsoft

[MURATA Makoto]

John,

2015-02-07 9:05 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:

>  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.
>

Understood.  Nevertheless MS-OFFCRYPTO provides
a good basis.


> 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.
>
>
>

The Japanese mirror of SC34 got together and discussed your mail.


>
>
> 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.
>
>
>

We believe that sufficient infrastructure for the level A is already
present  (especially in Europe and Japan) and that the current
infrastructure continues to be improved.

 > - 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.”)
>


 Reasons for mandating SigningTime should be made clear.


>
>
> 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.
>

We then propose to reference RFC 3161 and require 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.
>
>
>


XAdES does not mandate the use of -C or -X for -A or -X-L.  In other
words, -A without -C and -X is allowed, and -X-L without -C and -X is
also allowed.  Since -C and -X on top of -A or -X-L leads to
additional running cost, this optionality is very important.

Unfortunately, MS Office does not allow this optionality. It rather
mandates the use of -C and -X for -A or -X-L.  Since MS Office is
widely used, other implementors of XAdES will be forced to use -C and
-X thus causing additional running cost.  We hope that MS Office
be updated and that the next revision of OPC explicitly require
implementations to accept -A and -X-L without -C or -X.

Regards,
Makoto

 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
>



-- 

Praying for the victims of the Japan Tohoku earthquake

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