XAdES elements in OFF-CRYPTO of Microsoft

Fri Jan 23 08:09:19 CET 2015

John,

2015-01-16 5:05 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:

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

MS Office reports an error when C is not used.

Regards,
Makoto

>
>
> (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>:
>
>  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
>

-- 

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/20150123/5ed5649a/attachment.html>