OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [bdxr-comment] Comments to SMP spec


Dear Juan Carlos

Once again thank you for your comments to the SMP 1.0 specification. The TC was able to finalize elaborations on your comments at our TC meeting yesterday, and came to the following conclusions:

Comment 1:

We agree with your observation that there is an inherited redundancy in the “PEM base 64” encoding requirement, and we agree with your suggestion to remove “PEM” from the specification so as to not cause confusion. The resulting work product with your comment implemented is available here:

https://www.oasis-open.org/committees/download.php/58374/bdx-smp-v1.0-wd09.zip

The above working draft was furthermore approved by the TC as a Committee Specification Draft, and in the coming days we will be voting on approving the Draft as Committee Specification.

Comment 2:

ETSI EN 319 132 (XAdES digital signatures) is already supported by SMP 1.0 through the normative reference to, and use of XML DSig. Any user of SMP who wish to include XAdES in their implementation may do so freely and without restrictions using the current version of SMP (1.0). No change to the SMP specification is required for this.

The OASIS BDXR TC works on developing specifications that facilitate the exchange of business documents in a 4-cornered model. In this work we focus on the 4-cornered architecture, and leave specific policy decisions (such as whether to include XAdES profiles) for implementers to make based on their specific business requirements. Notwithstanding, we recognize the importance and relevance of XAdES and in our more recent specification for a Business Document Envelope (BDE) we have included XAdES schemas in the BDE schema tree for XML validation as a convenience to users choosing to implement XAdES. We will gladly consider a similar approach for the next version of SMP, which would then make a note on XAdES relevant for the SMP specification. I hope we may get back to you at that time to validate that we are including the correct versions etc. of XAdES.

On behalf of the TC I would like to use this opportunity to once again recognize the importance of XAdES, and to appreciate the work that ETSI is doing in this space.

Best regards,

Kenneth



On 6/2/16, 8:08 PM, "bdxr-comment@lists.oasis-open.org on behalf of Kenneth Bengtsson" <bdxr-comment@lists.oasis-open.org on behalf of kbengtsson@efact.pe> wrote:

Thank you very much Juan Carlos for your input. I am sharing your observations with the BDXR TC for further analysis and comments.

Best regards,

Kenneth


On 6/2/16, 9:12 AM, "bdxr-comment@lists.oasis-open.org on behalf of Juan Carlos Cruellas" <bdxr-comment@lists.oasis-open.org on behalf of cruellas@ac.upc.edu> wrote:

>Dear all,
>
>I would like to make two comments to the SMP draft specification.
>
>1. The SMP draft specification. specifies that the <ds:X509Certificate> 
>element MUST contain "the signer’s X.509 certificate as PEM base 64 
>encoded X509 DER value".
>
>I am not sure about the implications of the "PEM base 64". I do not know 
>if this means that the content of the element is exactly the same as the 
>content specified in the XML Signature W3C Recommendation (which is a 
>normative reference of the SMP document, and which is the one that has 
>defined, in its syntax and semantics the <ds:X509Certificate>) or not. 
>In the end the text in that specification is: "The X509Certificate 
>element, which contains a base64-encoded [X509V3] certificate", without 
>the "PEM" before, and I am not sure of the implications of this word in 
>terms of contents.
>
>I have certainly seen the files containing the base 64 encoded X509 
>certificates with the first line indicating the start of the certificate 
>and the last one indicating the end of the certificate, but I am not 
>sure if this is what the document actually means, as there is not an 
>specific reference next to the text.
>
>In your view, would the "PEM base 64" lead to a different content than 
>the "base 64" within the <ds:X509Certificate>?. If not, may I suggest to 
>remove the "PEM" so that this does not generate doubts between readers?
>
>If you think that this is going to lead to different contents, I would 
>like to make the following remark: as I said the <ds:X509Certificate> is 
>an element defined and specified by XML Sig 1.1, which is a normative 
>reference for the SMP document. This document defines both, its syntax 
>and semantics. At this document no mention is done to "PEM base 64". 
>Actually, looking to the test suite generated by the XML Signature group 
>that produced the first version of the specification, the contents of 
>any <ds:X509Certificate> were plain base 64 encoding. IF the SMP 
>specifies a different content for the <ds:X509Certificate>, I would say 
>that this means a change in its specification, which could raise  
>interoperability problems in many applications that generate and manage 
>regular base 64 encodings. A number of interoperability tests on XAdES 
>signatures, which build on XML Signatures, have been conducted during 
>the last years and all the implementations (which would logically 
>include XML signatures implementations) generate the regular content as 
>it is generally understood from the reading of XML Sig specifications, 
>and as far as I remember nobody rose in those interoperability events 
>(which accumulate a high number of participants from all over the world 
>-including European, American, and Asian participants) the suggestion of 
>using a different content. Consequently I would like to kindly request 
>that if the "PEM base 64" would lead to different contents, the 
>committee reviews this decission and drops from the text the "PEM".
>
>2.  The European Union Member States National Standardisation 
>Organisations have recently approved the XAdES specification published 
>by ETSI as ETSI EN 319 132: "XAdES digital signatures" as an European 
>Standard. XAdES is also being adopted as a proper signature format for 
>OASIS ODF, and other relevant document formats, as OOXML. In fact, ISO 
>is also incorporating XAdES as a signature format in a number of 
>specifications: ISO/IEC JTC1 SC34/WG4 "Document description and 
>processing languages" is now incorporating XAdES as a way of signing the 
>OOXML documents whose format is standardizing. Other committees from ISO 
>are also specifying XAdES profiles, as ISO TC 154 "Processes, data 
>elements and documents in commerce, industry and administration". I 
>would like to kindly request that ETSI EN 319 132 is included as an 
>informative reference within the SMP specification
>
>Best regards
>
>Juan Carlos Cruellas.
>
>-- 
>This publicly archived list offers a means to provide input to the
>OASIS Business Document Exchange (BDXR) TC
>
>In order to verify user consent to the Feedback License terms and
>to minimize spam in the list archive, subscription is required
>before posting.
>
>Subscribe: bdxr-comment-subscribe@lists.oasis-open.org
>Unsubscribe: bdxr-comment-unsubscribe@lists.oasis-open.org
>List help: bdxr-comment-help@lists.oasis-open.org
>List archive: http://lists.oasis-open.org/archives/bdxr-comment/
>Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
>List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>Committee: http://www.oasis-open.org/committees/bdxr
>Join OASIS: http://www.oasis-open.org/join/
>
>
>Thank you for offering to provide input to the
>OASIS Business Document Exchange (BDXR) TC.
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]