XAdES elements in OFF-CRYPTO of Microsoft

[MURATA Makoto]

Miyachi-san (an attendee of the Kyoto meeting) agrees that
idXAdESReferenceObject is not needed in OPC V2.  We
rely on SignedInfo instead.

Regards,
Makoto

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

>  I nearly forgot, I compared the XAdES-specific requirements in
> MS-OFFCRYPTO and those we looked at last year in ODF (ODF 1.2 Part 3,
> section 5.3).  Here is what I found.
>
>
>
> SignedSignatureProperties > SigningCertificate -- in BOTH
>
> SigningTime – “should” in ODF, “MUST” in OFFCRYPTO
>
> EncapsulatedTimeStamp (DER-encoded ASN.1) -- in BOTH
>
> CompleteCertificateRefs/CompleteRevocationRefs -- in OFFCRYPTO only
>
> SigAndRefsTimestamp for refs to validation data -- in BOTH
>
> CertificateValues/RevocationValues -- in OFFCRYPTO only
>
> Reference element for digest of SignedProperties
>
> -- ODF: child of SignedInfo
>
> -- OFFCRYPTO: child of SignedInfo (preferred) or Object > Manifest (with
> id=”idXAdESReferenceObject”)
>
>
>
> They’re pretty similar, MS-OFFCRYPTO has slightly tighter requirements.
> So, no notable differences between the two that we would need to research.
> The XAdES requirements we’ll want to add to Part 2 look fairly well known
> to the industry.
>
>
>
> *From:* John Haug [mailto:johnhaug at exchange.microsoft.com]
> *Sent:* Thursday, January 15, 2015 12:05 PM
> *To:* MURATA, Makoto (eb2m-mrt at asahi-net.or.jp); SC34
> *Subject:* RE: XAdES elements in OFF-CRYPTO of Microsoft
>
>
>
> 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 <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/20150124/d60056e6/attachment.html>