Вводный критический обзор SDK "Kalkan" от НУЦ РК.

Начну пожалуй я издалека, чтобы дать общую картину прежде чем погрузиться в детали реализаций.

Есть у нас в Республике Казахстан  (РК) организация которая выдает электронной цифровой подписи ( ЭЦП)  физическим и юридическим лица.  Называется эта  организация  Национальный  удостоверяющий  центр  РК  (НУЦ РК) . И все информационные системы (ИС) которые работают для граждан и фирм нашей страны должны стремиться использовать  эти ЭЦП для аутентификаций своих пользователей.  Таким образом гражданин или  фирма могут один набор ЭЦП использовать во  всех ИС, и в первую очередь это относиться к службам электронного правительства РК.  В текущем году в силу ряда причин НУЦ  РК меняет механизм шифрования ЭЦП.   Соответственно всем  ИС которые используют их ЭЦП нужно также обновить свое программное обеспечение. Для этих целей НУЦ РК выпустило новый SDK и назвала его "Kalkan" и сейчас раздает эту SDK "Kalkan" всем нуждающимся  организациям РК. Разработчиками ИС в этих организациях необходимо интегрировать SDK "Kalkan" в свои ИС. До SDK "Kalkan"  НУЦ  РК выпускала другую  SDK "Iola".

НУЦ РК  человеку с улицы свой SDK "Kalkan" не даст. Вы должны будете доказать им, что работает на благо Казахстана и т.д. От сюда у них есть ограничение на распространения своего SDK. Из за этого ограничения,  я не могу включить их либы и сертификаты в свой пример. Чтобы он запускался сразу из коробки. Предполагается, что вы каким то образом уже  получили их SDK "Kalkan" и когда вы развернете мой пример, то добавите в него недостающие вручную.

На этом с общей картиной закончим и перейдем к моему участию в этой историй.  

С февраля 2014 года  одной из основных моих задач стала модернизацией ИС которая занимается сбором статистических данных. Сразу хочу оговориться что эту ИС проектировал и писал не я, она мне досталось как "наследство".  Ту часть ИС которая работала с SDK "Iola" я не трогал особо, так как были более серьезные проблемы с другим функционалом ИС. Но не будем о грустном.

Где то в июле 2015 я как раз подошло время перехода на новый SDK "Kalkan". Мой анализ SDK "Kalkan" показал что в SDK, как это не странно, нет примеров его использования на сервере. От НУЦ РК пришла  только бумага с требованием что они хотят чтобы я сделал. В этой бумажке восемь пунктов шесть из которых реализованный в моем примере. На вопросы с их форуме о том что нужен пример,  мне посоветовали разобраться JCE.  Думаю это их текущая позиция касается и всех остальных десятков разработчиков которые вздумают использовать их криптопровайдер.

С моей точки зрения здесь они не правы. Дело не в том, что мне тяжело изучит JCE и сопутствующие с ним технологий. Скилл  обучения - одно из важнейших качеств программиста и задачи которые передо мной ставятся,  вынуждают меня учиться чему-то новому постоянно. Думаю и у остальных программистов аналогичная ситуация.  Тут вопрос не в том "могу я это сделать или нет?" .Тут вопрос в том "Зачем мне это делать?". 

Зачем мне разбираться с их криптопровайдером,  с его использованием, с JCE  и т.д. если ребята из НУЦ РК уже это сделали?  Эти программисты НУЦ РК  наверняка лучше меня знают все эти тонкости работы с криптопровайдером. Так почему б им не довести все до логического конца?

Не знаю точно сколько ИС используют их ЭЦП, но в их списке рассылки 97 организаций.  Из это  цифры предположим, что у нас в РК  будет полсотни таких ИС. Это значит, что как минимум 50 программистов буду проделывать по сути одну и ту же работу.  У мне ушло на изучение проблемы и написание кода как минимум три недели. Три недели которые я, как и остальные 50 программистов, мог потратить на решение проблем своей ИС . Проблем которые кроме меня никто не может решить в отличий от проблем с SDK "Kalkan".

Например нам нужно проверить правильно ли подписаны данные или нет . Почему б не сделать класс-утиллиту с методом isGoodSignature. Этот метод давал бы нам булевый ответ и всю работу с криптопровайдером прятал бы внутри себя (инкапсулировал).

Надо также учитывать, то что программисты  иногда делают ошибки. Где гарантия того что никто из этих 50 не ошибется. НУЦ РК предполагает что если мы пришлем им бумажку о том мы выполнили их требования , то так оно и действительно будет?  И как они проверят это утверждения?   Мне кажется что это просто бюрократический подход.  Я бы на их месте решал бы проблему в корне, не давал бы программистам разных ИС пространство, где они могут ошибиться. То есть дополнительно к самому криптопровайдеру, написал бы класс утилиту со списком часто встречающихся функций необходимых  программистам других ИС.

Я бы понял бы такую ситуацию если бы это был некоммерческий open-source проект.  Но здесь у нас целое госпредприятие которое не щадит время  других программистов,  а значит и деньги других государственных структур.

В суммируя моего недовольство НУЦ РК получаем два пункта:

1) В SDK должен быть пример его использования. Серьезно, в других SDK которые я видел обычно так делают.  Я говорю например про пример проверки подписи на сервере.

2) SDK слишком низкоуровневое. Слишком много времени уходит на изучение и написание кода, хотя это можно было бы избежать.  По мне так это недочет в требованиях к  SDK.

 По мимо жалоб на НУЦ РК, мое недовольство так же вылелось в то,  что я сделал пример того как я использую их криптопровайдер. Описание этого примера и ссылка на его скачивание будет уже в следующем посте.