FW: [bdxr-comment] Comments to SMP spec

[Kenneth Bengtsson <kbengtsson@efact.pe>]

Dear all

I am in deep water here, so any input would be greatly appreciated.. This is what I can make out of it:

1) Remove the “PEM” from “PEM base 64 encoded X509 DER value”:

I think the commenter has a point here. We use “PEM base 64” consistently in the spec. My understanding of PEM is that it is a base 64 formatted X.501 DER certificate in between “BEGIN CERTIFICATE” and “END CERTIFICATE” lines of text, however that is not how it is currently implemented (at least not with the “BEGIN CERTIFICATE” / “END CERTIFICATE” lines). We had a discussion about this in PEPPOL a number of years back, and my feeling is that “PEM” is legacy from the first PEPPOL versions of SMP and should be removed.

Any thoughts?

2) Add ETSI EN 319 132 as informative / non-normative reference.

My opinion is that for something to be added as a reference, it must have some relation to the text of the specification. I’m not sure if that is the case here (and I might be completely wrong!). That’s not to say that we shouldn’t include the subject of XAdES digital signatures in the spec at some point, but perhaps this should be referred to a next version 1.1 or 2.0 of SMP?

Any thoughts?

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