Инфраструктура управления открытыми ключами (PKI) Улучшения
для J2SE 5

1. Введение

Этот документ описывает улучшения PKI, которые были сделаны к J2SE 5.0 и как использовать их.

Следующие улучшения PKI были сделаны в версии 5.0 платформы JavaSE:

Онлайновый Протокол Службы Сертификата (OCSP)
Поддержка API косвенных списков аннулированных сертификатов (CRL)
Разъясненное использование отличительного имени в API CertPath
Переданное соответствие RFC 3280 PKIX тестирует комплект
Сделанный java.security.cert. Нефинал PolicyQualifierInfo
Добавленный больше сертификатов CA
PKCS#11 Поддержка
Улучшенный PKCS#12 реализация
Улучшенная поддержка TrustManager

Онлайновый Протокол Службы Сертификата (OCSP)

Клиентская поддержка Онлайнового Протокола Состояния Сертификата (OCSP) как определено в RFC 2560 была добавлена в этом выпуске. Проверкой OCSP управляют следующие пять, новые свойства безопасности:

Имя свойства	Описание
`ocsp.enable`	Значение этого свойства является любой истиной или ложью. Если это правда, проверка OCSP включается, делая проверку аннулирования сертификата; если ложь или не набор, проверка OCSP отключается.
`ocsp.responderURL`	Значением этого свойства является URL, который идентифицирует расположение респондента OCSP. Вот пример. ocsp.responderURL=http://ocsp.example.net:80 По умолчанию расположение респондента OCSP определяется неявно от проверяемого сертификата. Свойство используется, когда расширение Доступа информации о Властях (определенный в RFC 3280) отсутствует в сертификате или когда это требует переопределения.
`ocsp.responderCertSubjectName`	Значение этого свойства является подчиненным именем сертификата респондента OCSP. Вот пример. ocsp.responderCertSubjectName="CN=OCSP Responder, O=XYZ Corp" По умолчанию сертификат о респонденте OCSP является сертификатом выпускающего проверяемого сертификата. Это свойство идентифицирует сертификат о респонденте OCSP, когда значение по умолчанию не применяется. Его значение является строковым отличительным именем (определенный в RFC 2253), который идентифицирует сертификат в наборе сертификатов, предоставленных во время проверки допустимости пути свидетельства. В случаях, где одно только подчиненное имя не достаточно, чтобы однозначно определить сертификат, тогда оба, свойства `ocsp.responderCertIssuerName` И `ocsp.responderCertSerialNumber` должны использоваться вместо этого. Когда это свойство устанавливается, тогда те два свойства игнорируются.
`ocsp.responderCertIssuerName`	Значение этого свойства является именем выпускающего сертификата респондента OCSP. Вот пример. ocsp.responderCertIssuerName="CN=Enterprise CA, O=XYZ Corp" По умолчанию сертификат о респонденте OCSP является сертификатом выпускающего проверяемого сертификата. Это свойство идентифицирует сертификат о респонденте OCSP, когда значение по умолчанию не применяется. Его значение является строковым отличительным именем (определенный в RFC 2253), который идентифицирует сертификат в наборе сертификатов, предоставленных во время проверки допустимости пути свидетельства. Когда это свойство устанавливается тогда, свойство `ocsp.responderCertSerialNumber` должно также быть установлено. Отметьте, что это свойство игнорируется, когда свойство `ocsp.responderCertSubjectName` было установлено.
`ocsp.responderCertSerialNumber`	Значение этого свойства является порядковым номером сертификата респондента OCSP, Вот пример. ocsp.responderCertSerialNumber=2A:FF:00 По умолчанию сертификат о респонденте OCSP является сертификатом выпускающего проверяемого сертификата. Это свойство идентифицирует сертификат о респонденте OCSP, когда значение по умолчанию не применяется. Его значение является строкой шестнадцатеричных цифр (двоеточие, или разделители пространства могут присутствовать), который идентифицирует сертификат в наборе сертификатов, предоставленных во время проверки допустимости пути свидетельства. Когда это свойство устанавливается тогда, свойство `ocsp.responderCertIssuerName` должно также быть установлено. Отметьте, что это свойство игнорируется, когда свойство `ocsp.responderCertSubjectName` было установлено.

Эти свойства могут быть установлены или статично в файле $JAVA_HOME/jre/lib/security/java.security Среды выполнения Java, или динамически использовании метода java.security.Security.setProperty().

По умолчанию проверка OCSP не включается. Это включается, устанавливая свойство ocsp.enable в "true". Использование остающихся свойств является дополнительным. Отметьте, что, включая OCSP проверка только имеет эффект, если проверка аннулирования была также включена. Проверка аннулирования включается через метод PKIXParameters.setRevocationEnabled().

OCSP проверяющие работы в соединении со Списками аннулированных сертификатов (CRL) во время проверки аннулирования. Ниже сводка взаимодействия OCSP и CRL. Failover к CRL происходит, только если с проблемой OCSP встречаются. Failover не происходит, если респондент OCSP подтверждает или что сертификат был отменен или что это не было отменено.

PKIXParameters RevocationEnabled (default=true)	`ocsp.enable` (default=false)	Поведение
истина	истина	Проверка аннулирования, используя OCSP, failover к использованию CRL
истина	ложь	Проверка аннулирования, используя CRL только
ложь	истина	Никакая проверка аннулирования
ложь	ложь	Никакая проверка аннулирования

См., что API Пути Сертификации Java Программирует Руководство для деталей о проверке аннулирования и Списках аннулированных сертификатов.

Поддержка API Косвенных Списков аннулированных сертификатов (CRL)

Косвенные CRL являются списками аннулированных сертификатов, которые включают записи для сертификатов от выпускающих кроме выпускающего CRL. В J2SE 5, два изменения были произведены в API CertPath, чтобы лучше поддерживать косвенные CRL.

У java.security.cert.X509CRL class есть метод, getRevokedCertificate(BigInteger), для того, чтобы получить запись CRL, данную порядковый номер сертификата. Однако, для косвенного CRL, порядковый номер не однозначно определяет сертификат. В J2SE 5, перегруженная форма getRevokedCertificate() была добавлена для того, чтобы получить запись CRL, данную сертификат.

До J2SE 5, java.security.cert.X509CRLEntry у class не было никакого метода для того, чтобы получить выпускающего сертификата, описанного записью CRL. В J2SE 5, метод, getCertificateIssuer(), был добавлен, чтобы адресовать этот разрыв.

Разъясненное Использование Отличительного имени в API CertPath

У API CertPath есть конструкторы и методы, которые принимают, что байтовые массивы и строки представляют отличительные имена. Однако, в некоторых классах, это испытывало недостаток в подобных перегруженных формах, которые принимают, что X500Principal представляет отличительные имена. Использование X500Principal, чтобы представить отличительное имя предпочитается, потому что это более эффективно и соответственно введено. Следующие методы были добавлены к API CertPath.

java.security.cert.TrustAnchor

public TrustAnchor(X500Principal caPrincipal, PublicKey pubKey,
    byte[] nameConstraints);
public final X500Principal getCA();

java.security.cert.X509CertSelector

public X500Principal getIssuer();
public void setIssuer(X500Principal issuer);
public X500Principal getSubject();
public void setSubject(X500Principal subject);

java.security.cert.X509CRLSelector

public void setIssuers(Collection<X500Principal> issuers);
public void addIssuer(X500Principal issuer);
public Collection<X500Principal> getIssuers();

Методы getSubjectDN() и getIssuerDN() в X509Certificate class и getIssuerDN() в X509CRL, class проблематичен, потому что их спецификации говорят, что они возвращают отличительное имя, не будучи определенными о его формате. Следовательно, различные реализации могут возвратить специфичные для реализации объекты, приводящие к приложениям, которые имеют плохую функциональную совместимость или непереносимы. Использованию этих методов строго обескураживают. Вместо этого приложения должны использовать методы, которые возвращают экземпляр X500Principal.

Переданные PKIX Complaince Тестируют Комплект

Реализация CertPath в провайдере солнца в J2SE 5 передала Тестовый Комплект Функциональной совместимости С открытым ключом (PKITS).

Сделанный java.security.cert. Нефинал PolicyQualifierInfo

До J2SE 5, java.security.cert.PolicyQualifierInfo был заключительный class. Это препятствовало тому, чтобы пользователи создали подклассы и добавили методы, которые возвращают поля различных типов спецификаторов политики. В J2SE 5, этот class был сделан незаключительным, но следующие методы были сделаны заключительными, чтобы сохранить class' контракт неизменности.

public final String getPolicyQualifierId()
public final byte[] getEncoded()
public final byte[] getPolicyQualifier()

Добавленный Больше Сертификатов CA

Следующий CA (Центр сертификации) сертификаты был добавлен к файлу cacerts в каталоге lib/security установки Java.

  Alias name: equifaxsecureebusinessca1
  Owner: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US

  Alias name: equifaxsecureca
  Owner: OU=Equifax Secure Certificate Authority, O=Equifax, C=US

  Alias name: geotrustglobalca
  Owner: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US
   
  Alias name: equifaxsecureglobalebusinessca1
  Owner: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
  
  Alias name: equifaxsecureebusinessca2
  Owner: OU=Equifax Secure eBusiness CA-2, O=Equifax Secure, C=US

  Alias name: verisignclass1g3ca
  Owner: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c)
  1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, 
  O="VeriSign, Inc.", C=US
  Issuer: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 
  1999 VeriSign, Inc. 
  - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

  Alias name: verisignclass2g2ca
  Owner: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized 
  use only", OU=Class 2 
  Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized
  use only", OU=Class 2 Public Primary Certification Authority - G2, O="VeriSign,
  Inc.", C=US

  Alias name: verisignclass3g3ca
  Owner: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c)
  1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, 
  O="VeriSign, Inc.", C=US
  Issuer: CN=VeriSign Class 3 Public Primary Certification Authority - G3, OU="(c) 
  1999 VeriSign, Inc. 
  - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

  Alias name: verisignclass1g2ca
  Owner: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized 
  use only", OU=Class 1 
  Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized
  use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign,
  Inc.", C=US

  Alias name: verisignclass2g3ca
  Owner: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c)
  1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, 
  O="VeriSign, Inc.", C=US
  Issuer: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 
  1999 VeriSign, Inc. 
  - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

  Alias name: verisignclass3g2ca
  Owner: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized 
  use only", OU=Class 3 
  Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  Issuer: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized
  use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign,
  Inc.", C=US

PKCS#11 Поддержка

Криптографический Маркерный Стандарт Интерфейса, PKCS#11, является стандартом, который определяет собственные интерфейсы программирования к криптографическим маркерам, таким как аппаратные средства криптографические акселераторы и Смарт-карты. В J2SE 5, поддержка была добавлена для PKCS#11. Это означает, что приложения PKI могут использовать PKCS#11 маркеры (такие как Смарт-карты) как keystores. См. PKCS#11 Руководство для получения дополнительной информации о том, как использовать PKCS#11 маркеры в качестве keystores.

Улучшенный PKCS#12 Реализация

PKCS#12 (Стандарт Синтаксиса Exchange Персональных данных) определяет переносимый формат для хранения и/или транспорта закрытых ключей пользователя, сертификатов, разных секретов, и других элементов. J2SE 1.4.x оказывал поддержку только для чтения для PKCS#12 keystores, и только для небольшого количества алгоритмов защиты. Улучшенный PKCS#12 keystore в J2SE 5 поддерживает больше алгоритмов защиты (таких как поддерживаемые популярными браузерами) и также пишущий/обновляет в keystore. Это улучшается, функциональная совместимость PKCS#12 keystores импортировал/экспортировал Java SE, браузеры, и другие приложения безопасности.

Улучшенная Поддержка TrustManager

По умолчанию, провайдер SunJSSE в J2SE 5 использования PKIX-совместимый доверительный менеджер X509. См. Новые функции и возможности в Справочнике JSSE для деталей.

Свяжитесь с Нами

Инфраструктура управления открытыми ключами (PKI) Улучшения для J2SE 5