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: Comments to SMP spec


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.


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