https://tools.ietf.org/html/rfc5652 permits the "Code Components" of the RFC to be extracted under a simplified BSD licensing term. It would be great to update the AUTHORS file in libksba to refer to the simplified license (as well as to refresh the ASN.1 specifications with the latest ASN.1 module).
Description
Description
Event Timeline
Comment Actions
That is not a functional feature request and I see no value in chnaging data structures just for being up to the latest RFC. Actually the ASN.1 is not from an RFC but from a specific X.509 profile. For CMS most parsing is anyway done with handcrafted code.
Comment Actions
As I want to keep this tracker clean I would say this is a Wontfix at least until someone (DKG?) provides an argument what would be gained and why we should do this.
Wishlist for me is something that we actually want to do but have not yet found the time to do.
Comment Actions
If the ASN.1 is not from an RFC, then the AUTHORS file should not claim that it is from an RFC.
If it *is* from the RFC, then discussion on pkg-gnutls-maint describes a concrete problem that makes it difficult for the maintainer of this package to keep it up to date in debian, due to the licensing constraints which appear to make cms.asn1 (or anything that comes from RFC 2630 non-DFSG-free. In particular:
However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
That thread additionally points out that not all of the definitions are covered by RFC 5652, and there are additional problems with the definitions that currently live in RFC 3370. I think we can encourage the IETF to relicense RFC 3370 if we need to, but libksba should be clear about where its source comes from, and should make sure that it's all either free software, or has explicit explanations of why the apparent licensing terms from RFC 2630 do not apply to it.
If libksba is not maintained in debian, i'll probably need to drop gpgsm from the gnupg package, and maybe disable some chunks of dirmngr as well. That sounds difficult and annoying and problematic.
I've removed "wontfix" from this bug report in the hopes that it will actually get fixed one way or another, and so that we don't demotivate the debian maintainer of libksba, who hasn't made an upload to debian since 2016-09-03 due to getting stuck on this issue.
But if it gets set to "wontfix" again, i guess i'll start trying to figure out how to rip libksba out from the gnupg package, which would make me pretty sad.
Comment Actions
Thanks for the explanation.
I only changed it to wontfix initially because I felt "Whishlist" inappropriate after werners comment and did not know the reasons behind this request.
Comment Actions
Perhaps i wasn't clear enough in the earlier messages on this thread. The inclusion of restrictively-licensed code in a file that also claims LGPL/GPL appears to be an unredistributable license. Could you please clarify why the GPL or LGPL applies to libksba while it contains src/cms.asn in its current form?
If that's not possible, perhaps you could update src/cms.asn to one of the newer specifications which contains more permissively-licensed code components.
Comment Actions
I did some work (since Debian is important for us).
Please have a look at my topic branch: gniibe/fix-4487
or:
https://dev.gnupg.org/source/libksba/history/gniibe%252Ffix-4487/
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libksba.git;a=shortlog;h=refs/heads/gniibe/fix-4487
I did this, so that we can confirm how to proceed. Do you mean something like this topic branch, @dkg ?
I don't know how RFC3370 matters. For now, the topic branch is not yet correct/fully implemented. I wonder if we can use the code from RFC 5250, or what shall we do for Extensions, UniqueIdentifier, and GeneralNames.
Well, frankly speaking, I don't think old cms.asn is a kind of copyright license violation, but I understand the maintainer's consideration.
Comment Actions
@gniibe thank you!
Yes, your fix-4487 branch looks like just the sort of clarification i was asking for. (i have not tested the functionality of the changes; i'd be counting on libksba's test suite to ensure that nothing is broken)
I would hope that your view of the old cms.asn is correct -- i know several of the authors/editors of the drafts it was derived from personally, and i can't imagine any of them being upset about the reuse of their ASN.1 code components in libksba. However, having the code pulled from unambiguously permissively-licensed documents makes the situation much clearer.
@ametzler1 if you have any thoughts or preferences about these changes, please follow up here.
I hope these changes get merged!
Comment Actions
Comparing old cms.asn and new cms.asn, now I understand how RFC 3370 matters. I added those things back from RFC 5911 (which cites RFC 3370) which comes with BSD license for code.
Comment Actions
I pushed more changes to include modules in RFC 5911 and RFC 5912.
Missing definitions (comparison old and new) are:
Found in RFC 2311:
sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
oiw(14) secsig(3) algorithm(2) 26 }
md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) digestAlgorithm(2) 5 }
rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
Found in RFC2459:
id-dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) x9-57 (10040) x9cm(4) 3 }... which is now obsolete.
I think it's done now. I did my best to clarify things.
Comment Actions
RFC 5280 only addresses about BCP78 and not about TLP, while RFC 5652, RFC 5755, RFC 5911 and RFC 5912 address explicitly about TLP. In this situation, I wonder if it's better to take the definitions of Extensions, UniqueIdentifier, and GeneralNames from RFC 5280. To be conservative, I don't include them now.
Comment Actions
gniibe wrote:
RFC 5280 only addresses about BCP78 and not about TLP, while RFC 5652, RFC 5755, RFC 5911 and RFC 5912 address explicitly about TLP. In this situation, I wonder if it's better to take the definitions of Extensions, UniqueIdentifier, and GeneralNames from RFC 5280.
Afaiu rfc 5280 is too old (May 2008), TLP with its code components exception only applies to RFCs published on or after Nov 11, 2008.
Comment Actions
Won't fix because there is no need for it. ASN.1 modules are the formal description of a protocol and as such not copyrightable.
We won't touch them anyway because that would need chnages to other parts of the code as weel. In fact the long term plan is to get rid of the table driven parsers and re-license libskba under the LGPL