Bei JCE handelt es sich, wie bei anderen Java-APIs auch, primär um eine Spezifikation. Sie definiert eine Plug-in-Architektur für Verschlüsselungsmodule ("Service-Provider"), die unabhängige Softwareentwickler in die Java-Plattform einfügen können. Die wesentliche Neuerung von JCE 1.2.1 besteht darin, dass sich über diese Schnittstelle nur Code einklinken lässt, wenn er von autorisierter Stelle digital signiert wurde.
Auf den ersten Blick könnte diese Änderung vielleicht danach aussehen, als schütze sie Anwender vor zweifelhaften Krypto-Programmen - wobei bis dato unklar ist, wer außer Sun derartige Module überhaupt absegnen darf. Tatsächlich ist diese Funktion aber in erster Linie politisch motiviert und bringt für Unternehmen außerhalb der USA eine Verschlechterung in puncto Geheimhaltung. Bis zur Version 1.2 konnten beispielsweise europäische Softwarehäuser ohne Rücksicht auf amerikanische Exportbestimmungen Module für starke Verschlüsselungen schreiben, die sich in JCE einhängen ließen.
In der neuen Architektur aber soll sich die Länge des Schlüssels abhängig von Standort dynamisch ändern. Dazu benutzt JCE "jurisdiction policy files". Eine dieser Dateien repräsentiert die amerikanischen Exportbestimmungen, eine andere trägt den lokalen Gesetzen Rechnung. Unterscheiden sich die beiden Regelungen, so zieht JCE jene mit den strengeren Auflagen heran. Im KlarteXT:Das Maximum an Verschlüsselung definieren außerhalb Nordamerikas in jedem Fall die amerikanischen Exportrestriktionen, die lokalen Bestimmungen greifen nur, wenn sie noch strenger sind.
Abhängigkeit vom US-Recht wächst
Kritiker befürchten, dass die benötigte Signatur für Krypto-Module mit zusätzlichen Auflagen verbunden sein könnte (siehe dazu http://www.ibiblio.org/javafaq/reports/JCE_1.2.1.html). Hersteller müssen nämlich vorher das amerikanische Genehmigungsverfahren für den Export durchlaufen. In dessen Zuge werden Firmen häufig angehalten, mit amerikanischen Behörden zu kooperieren, beispielsweise Hintertüren für Geheimdienste wie die National Security Agency (NSA) einzubauen. Nicht gerade vertrauenserweckend sind zudem Äußerungen von Sun-Chef Scott McNealy, der sich über Sorgen um die Privatsphäre bei anderer Gelegenheit in arroganter Weise hinwegsetzte (http://www.wired.com/news/politics/0,1283,17538,00.html).
Sun hilft die erforderliche Signierung von Verschlüsselungsmodulen zumindest bei der Distribution von Java. Musste JCE vorher noch getrennt vom Java Developer Kit (JDK) heruntergeladen werden, kann die als exportfähig eingestufte Version 1.2.1 nun zusammen mit dem ganzen Paket vertrieben werden. Der als Referenzimplementierung mitgelieferte Provider beschränkt sich zudem auf schwache Verschlüsselung.
Da JCE als allgemein zugängliche Spezifikation vorliegt, können unabhängige Entwickler diese selbständig umsetzen und dabei auf die Signierung für Krypto-Module verzichten. Tatsächlich existiert schon eine Open-Source-Implementierung namens Cryptix (http://www.cryptix.org). Allerdings genießt die Sun-Variante den Vorteil, zukünftig Bestandteil des JDK zu sein und damit einen "offiziellen" Status zu erlangen. Beobachter halten es dennoch für möglich, dass Sun in JCE-Alternativen einen Anlass sehen könnte, das Signierungsverfahren auf weitere Java-APIs auszudehnen. Damit ließen sich nicht nur fremde JCE-Umsetzungen aus dem hauseigenen JDK aussperren, sondern im Prinzip alle unliebsamen Erweiterungen.