Конкретизация CRLReason

[agievich]

В СТБ 34.101.19 причины отзыва сертификата фактически не определены. Задано только перечисление

CRLReason ::= ENUMERATED {
  unspecified (0),
  keyCompromise (1),
  cACompromise (2),
  affiliationChanged (3),
  superseded (4),
  cessationOfOperation (5),
  certificateHold (6),
  -- значение 7 не используется
  removeFromCRL (8),
  privilegeWithdrawn (9),
  aACompromise (10) }

элементы которого понимай как хочешь.

О семантике некоторых кодов можно узнать только по внешним источникам. Например,

The 'removeFromCRL' reason code indicates that the certificate is, in fact, not revoked. The idea behind 'certificateHold' is to make a suspension, not a revocation: the PKI declares that the certificate should not be used until more information is made available (in a subsequent delta or full CRL), while not fully revoking the certificate, because revocation is a one-way trip. In that sense, the certificate was never revoked, and thus was not "unrevoked" either.

(Arguably, the 'certificateHold' and 'removeFromCRL' reason codes are a hack which encourages PKI owners to use revocation as an emergency suspension mechanism, i.e. a substitute for authorization, and that is a bad idea. Revocation is, by nature, an asynchronous mechanism, and does not work well for that. When a situation arises where you would want to put a certificate "on hold", the sane thing to do is to revoke the certificate and issue a new one.)

Здесь, в частности, говорится о том, что приостановка сертификата (certificateHold) -- это страный механизм, не соответствующий самой идее отзыва (см. также обсуждение приостановки в #35).

Предлагаю оставить только коды keyCompromise (компрометация лк), cACompromise (компрометация УЦ), affiliationChanged (смена работы?), superseded (смена сертификата? Reenroll?), cessationOfOperation (закрытие УЦ).

Для сравнения немецкий профиль CommonPKI разрешает только те же коды, за исключением superseded.

• [ ] Вписать superseded в Reenroll.

[pavlovkv]

А в случае какой-либо причины вне этого списка? Как рекомендуется в СТБ 34.101.19 не включать данное расширение? Тогда в стандарте надо указать, что в запросе на отзыв необязательно включать данное расширение. Я считаю, что если и сокращать количество причин, то помимо указанных выше добавить unspecified (0).

[agievich]

@pavlovkv Речь не идет об исключении расширения. Речь идет о его конкретизации: раскрытии семантики, которая в СТБ 34.101.19 (RFC5280) не раскрыта.

Решения:

1. Раскрыта семантика crlReason.
2. Исключены коды certificateHold, removeFromCRL, privilegeWithdrawn (последний код нужен при отзыве атрибутных сертификатов, которые в BPKI не рассматриваются).
3. В Reenroll сказано о необходимости использования superseded.
4. Небольшая либерализация: разрешено использовать расширение записи invalidityDate.