XAdES elements in OFF-CRYPTO of Microsoft

[John Haug]

Do you know what the basis is for thinking –C and –X are mandatory?  I assume he’s looking at the 5th and 6th bullets under 2.5.2.6 in MS-OFFCRYPTO.  I read these as conditionals – if you use validation data, then you must do it this way.

(1) Are there alternate ways to specify references to validation data other than as specified in XAdES 7.4 (and 4.4/4.4.3, which say signatures with validation data are –T and –C.)?  If so, the 5th bullet is just requiring one way where a choice exists.  If not and XAdES-C is the only way, the 5th bullet seems to just restate what XAdES-C requires.  I don’t see other ways and I might read that bullet as precluding use of XAdES-T, which I’m sure is the wrong interpretation.
(2) Are there alternate ways to specify time stamps on references to validation data?  It seems so: SigAndRefsTimeStamp and RefsOnlyTimeStamp.  In this case, MS-OFFCRYPTO appears to be simply requiring the use of one method where an option exists for implementers.  The mandate here appears to be use of XAdES-X type 1 and not XAdES type 2 if you use XAdES-X.


Furthemore, as agreed in Kyoto, we should allow EPES/BES, T, X-L, and A.
Yes.  As reference for today’s call, here are my relevant notes from our discussion and decisions at the Kyoto meeting.
What to specify

  *   Anything re: grace period?  NO - for implementers, not for file format.
  *   Which parts/relationships must/must not be signed? Part 2 does not currently say anything to this effect.  NO - for implementers, based on user scenario.
  *   Additional restrictions a la ODF? (for interoperability)  NEEDS RESEARCH
  *   Other restrictions? (disallow less useful levels?)
     *   e.g., BES/EPES plus ISO profile
     *   Don't mandate/prohibit, give guidance - normative SHOULD or informative NOTE
  *   Does OPC require signing a relationship that targets a part that is signed?  Don't think so (relationships can be signed, but not required).  Should this be mandated?  NO.
  *   RenewedDigests - mention this?
     *   Can reference new ETSI std once published (expected within the next year)
     *   Should only contain this addition since 1.4.2 (minor bug fixes from 1.4.1)
     *   Double-check for any changes, including namespace (all existing features should be in old namespaces, only new features in new ones)

From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: Thursday, January 15, 2015 5:20 AM
To: SC34
Subject: Re: XAdES elements in OFF-CRYPTO of Microsoft

Miyachi-san believes that the quoted paragraphs
allow five leveles of XAdES (EPES, T, C, X, X-L)
and mandate C and X.  He thinks
that tjhey should be optional.

Furthemore, as agreed in Kyoto, we should allow
EPES/BES, T, X-L, and A.

Regards,
Makoto

2014-12-27 18:21 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp<mailto:eb2m-mrt at asahi-net.or.jp>>:
Dear colleagues,

We have already agreed not to introduce
SignatureInfoV1.  The rest of XAdES elements
in OFF-CRYPTO is described in the following
subsection.  We probably have to tweak this
subsection since we would like to allow all
conformance levels of XAdES.

Regards,
Makoto


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. XAdES-EPES through
XAdES-X-L extensions are specified within a
signature. Unless otherwise specified, any optional
elements as specified in [XAdES] are ignored.  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. 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.

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

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

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

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

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

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.

A document compliant with this file format
SHOULD<33> place the Reference element specifying
the digest of the SignedProperties element within
the SignedInfo element. If the Reference element is
instead placed in a Manifest element, the containing
Object element MUST have an id attribute set to
"idXAdESReferenceObject".



--

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/20150115/81c73639/attachment-0001.html>