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

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-enotary message

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


Subject: Comment on spec


Arshad et al.:

I think this is a fine work. I do have one concern and I do not know
where it should be addressed; i.e., within the spec or in a
non-normative document annexed to it.

The concern is that there is insufficient explanation of the
cryptographic IPR constraints and that in the absence of a suitable
explanation, confusion and avoidance of the standard may ensue. For
example, digital signatures are discussed in the context of Apostilles
but not notarizations, where symmetric signatures predominate, but there
is no explanation to guide the user of the standard that I could find. 

I think we need to make clear that the methodology for cryptography is
intended to be all-inclusive but the ghost Arcanvs patent was a
constraint by virtue of OASIS IPR policy that prevented us from
including specific markup and examples of notarizations involving
classic PKI solutions (which did not also apply to Apostilles, hence the
difference); PKI solutions, however, should be rather trivial to adapt
by appropriate extensions to the standard for those who so desire and
are not concerned with the existence of such patents or possible
infringement of them; a specific grant of a royalty free license for
symmetric signatures was granted to the TC and through it to appropriate
users of the standard for symmetric signatures on notarizations; and for
that reasons, many of the examples refer to symmetric signatures and not
to classic digital signatures. However, the overall methodology should
not deter anyone with a desire to use classic cryptography in the
context of the standard, whatever its basis, without regard to possible
IPR, and otherwise incompatible cryptographic methods should be
employable as a technical matter interoperably by virtue of the overall
structure of the mark-up language.

I hope this is sufficiently clear.

Best regards to all.



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