Syntaxe rozšíření je obdobná syntaxi atributu relativního rozlišitelného
jména. Rozšíření je celá řada, uvedeme jako příklad alespoň následující
rozšíření.
Identifikátor tohoto objektu je:
keyUsage OBJECT IDENTIFICATOR :== {joint-iso-ccitt(2) ds(5) id-ce(29)
15}
hodnota atributu je:
KeyUsage ::= BIT STRING {
digitalSignature
(0),
nonRepudation
(1),
keyEncypherment
(2),
dataEncypherment (3),
keyAgreement
(4),
keyCertSign
(5),
cRLSign
(6)}
Jedná se tedy o řetězec bitů, podle nastavení jednotlivých bitů (1 nebo
0) je klíč k danému účelu možné používat či nikoliv.
Zodpovědnost za CA nižší úrovně je možné omezit právě pomocí tohoto rozšíření, tj. certifikát se rozšíří o číslo specifikující max. délku řetězce certifikátů.
Identifikátor objektu je:
basicConstrains OBJECT IDENTIFIER ::= {joint-iso-ccitt(2) ds(5)
id-ce(29) 19}
hodnota atributu je:
BasicConstrains ::== SEQUENCE {
cA
BOOLEAN DEFAULT FALSE,
pathLenConstraints
INTEGER OPTIONAL}
Nebezpečí spočívá totiž v tom, že si nějaký uživatel nechá vydat certifikát a posléze jej prohlásí za certifikát podřízené certifikační autority a začne nekontrolovatelně vydávat další certifikáty a zodpovědnost tak za ně automaticky přejde na původní CA.
Identifikátor cA vyjadřuje, že se jedná o certifikát CA (implicitně
se jedná o uživatelský certifikát). Celé číslo pathLenConstraints
omezuje délku řetězce certifikátů na uvedené číslo.
Žádosti nepodepsané soukromým klíčem žadatele CA zpravidla neakceptuje.
CA přijme žádost a verifikuje její obsah pomocí veřejného klíče uvedeného v žádosti, tím ověří nebyly-li údaje v žádosti cestou změněny.
Formát a způsob předání žádosti je součástí dokumentu "Certifikační politika CA", kterou vydává každá rozumná CA. Tento formát si tedy může každá CA určit sama. Avšak dnes klasickým formátem žádosti o certifikát je žádost podle normy PKCS#10:
CertificateRequest :== SIGNED SEQUENCE {
version
Version,
subject
Name,
subjecPublicKeyInfo SubjecPublicKeyInfo,
attributes [0]
IMPLICIT Attributes}
kde
Attributes :== SET OF Attribute
Attribut je opět dvojice skládajíce s identifikátoru objektu a hodnoty. Jednotlivé atributy obsahují dodatečné informace. Příkladem atributů mohou být atributy pro rozšířené certifikáty, attribut challenge-password pomocí kterého lze bezpečněji získávat CRL atp.
Ostatní položky jsme již vysvětlili u popisu struktury certifikátu. Např. version specifikuje verzi, tj. 0 specifikuje verzi 1 (1988).
Příklad žádosti o certifikát najdeme např. na certifikační autoritě https://www.ica.cz
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBHDCBxwIBADBkMQswCQYDVQQGEwJDUjEPMA0GA1UECBMGTW9yYXZhMQ0wCwYD
VQQHEwRCcm5vMQwwCgYDVQQKEwNQVlQxDDAKBgNVBAsTA1ZQVjEZMBcGA1UEAxMQ
YnVkaXMuYnJuLnB2dC5jejBaMA0GCSqGSIb3DQEBAQUAA0kAMEYCQQD7KAVqvt+a
Kz8eG8oOvZJ0+ooqtXNu/gXZ7oiDQdLEFrcHAVxkb7PJPewM7IvrArGBa/B0kLny
0Youn+SHjTfTAgEDoAAwDQYJKoZIhvcNAQEEBQADQQAKALvtdjXcQk7d4OCBitxI
g0p2O0i/UqcyNAKmUgC0rgNlyCaH0zHV2ZilE0SRLLcOHCGPtnkxJHKJDx3n+lRd
-----END NEW CERTIFICATE REQUEST-----
Tím se však nenecháme zaskočit a obratem si to převedeme z formátu PEM (tj. Base64) do ASN1 a DER (hexadecimálně):
SEQUENCE
30 82 01 1c
SEQUENCE
30 81 c7
INTEGER
:00
02 01 00
SEQUENCE
30 64
SET
31 0b
SEQUENCE
30 09
OBJECT
:countryName
06 03 55 04 06
PRINTABLESTRING :CR
13 02 43 52
SET
31 0f
SEQUENCE
30 0d
OBJECT
:stateOrProvinceName
06 03 55 04 08
PRINTABLESTRING :Morava
13 06 4d 6f 72
61 76 61
SET
31 0d
SEQUENCE
30 0b
OBJECT
:localityName
06 03 55 04 07
PRINTABLESTRING :Brno
13 04 42 72 6e
6f
SET
31 0c
SEQUENCE
30 0a
OBJECT
:organizationName
06 03 55 04 0a
PRINTABLESTRING :PVT
13 03 50 56 54
SET
31 0c
SEQUENCE
30 0a
OBJECT
:organizationalUnitName
06 03 55 04 0b
PRINTABLESTRING :VPV
13 03 56 50 56
SET
31 19
SEQUENCE
30 17
OBJECT
:commonName
06 03 55 04 03
PRINTABLESTRING :budis.brn.pvt.cz
13 10 62 75 64
69 73 2e 62 72 6e 2e 70 76 74 2e 63 7a
SEQUENCE
30 5a
SEQUENCE
30 0d
OBJECT
:rsaEncryption
06 09 2a 86 48 86 f7
0d 01 01 01
NULL
05 00
BIT STRING
03 49 00 30 46 02 41 00 fb
28 05 6a be df 9a 2b 3f 1e 1b ca
0e bd 92 74 fa 8a 2a b5 73
6e fe 05 d9 ee 88 83 41 d2 c4 16
b7 07 01 5c 64 6f b3 c9 3d
ec 0c ec 8b eb 02 b1 81 6b f0 74
90 b9 f2 d1 8a 2e 9f e4 87
8d 37 d3 02 01 03
cont [ 0 ]
a0 00
SEQUENCE
30 0d
OBJECT
:md5withRSAEncryption
06 09 2a 86 48 86 f7 0d 01 01 04
NULL
05 00
BIT STRING
03 41 00 0a 00 bb ed 76 35 dc 42 4e dd
e0 e0 81 8a dc 48 83
4a 76 3b 48 bf 52 a7 32 34 02 a6 52 00
b4 ae 03 65 c8 26 87
d3 31 d5 d9 98 a5 13 44 91 2c b7 0e 1c
21 8f b6 79 31 24 72
89 0f 1d e7 fa 54 5d
Je třeba vysvětlit způsob (příběh) jak se taková žádost vytvoří. CA má WWW-server, na kterém vystavuje HTTP-formuláře žádosti. Tento formulář obsahuje tág <keygen>, který při odeslání formuláře způsobí, že ještě před tím než je formulář odeslán, tak Netscape Navigátor vygeneruje dvojici veřejný/soukromý klíč. Soukromý klíč uloží na disk zašifrován heslem, o které je uživatel při odesílání formuláře požádán. Veřejný klíč je odeslán na WWW-server jako součást hodnoty pole, u kterého byl použit tág <keygen>. Je třeba zdůraznit, že se veřejný klíč doplňuje ještě o identifikaci a náhodné číslo a celé se to elektronicky podepíše soukromým klíčem.
Vystaví-li CA z této žádosti certifikát, pak uživatel jej pouhým kliknutím myši na link s vystaveným certifikátem může natahnou, podobně jako natahuje např. obrázky. Pouze se nezobrazí obrazek, ale menu sloužící pro ukládání certifikátu. Struktura takto natahované správy s certifikátem odpovídá běžné HTTP-zprávě, tj. běžné MIME-zprávě s hlavičkou Content-Type: application/x-x509-user-cert a tělem obsahující certifikát v PEM-formátu. Netscape Navigátor sám pozná, ke kterému soukromému klíči vystavený certifikát náleží.
WWW-server CA by zásadně neměl pracovat v protokolu HTTP, ale měl pracovat v protokolu HTTPS. Při komunikaci je nutná autentizace serveru, ale nikoliv autentizace uživatele (V SSL a tím i v HTTPS anonymní servery nesmí vyžadovat autentizaci uživatele!). Je tedy nutné si před tím, než začnete hledat formulář pro vyplnění žádosti o certifikát, obstarat certifikát WWW-serveru CA se kterým pracujete, aby vůbec byla možná komunikace v protokolu HTTPS. Takže ve hře jsou minimálně tři certifikáty:
C = CZ
SP = JM
L = Brno
O = PVT
OU = divize
CN = Cecil Operator
Email = ca-cert@brn.pvt.cz
SPKAC = MIG0MGAwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAoEKLD8/3ZXGfoK48lpLQUsYky4jXoXfc
xZkev8AcK7VLfVwdn4AfAuOWtIwEy5LHxSVYEf/biuOCF5xkYNQPmQIDAQABFgAwDQYJKoZIhvcNAQEE
BQADQQAmr9tDtXvTAm5TtUtQxye+Gv4E6hK+OotL/cwkF22wEx07GOxYJnYYLuFsN/sTg8fyVhBEcHG5
SYvaDB+O17cq
Přesto dnes (rok 1997) je tento formát žádosti o certifikát patrně nejpopulárnějším
formátem žádosti. Tento formát žádosti je vhodný pouze pro certifikáty
koncových uživatelů. Certifikáty serverů a certifikáty samotných certifikačních
autorit jsou i v produktech firmy Netscape vyžadovány v PEM-formátu, tj.žádost
podle PKCS#10 kódované Base64. (Je třeba poznamenat, že termín
PEM-formát je zavádějící, protože protokol PEM
má vlastní formát žádosti
o certifikát, který je mírně odlišný od normy PKCS#10, ale bohužel se to
často používá. Protokol PEM zná pouze žádosti o certikáty veze 1, umožňuje
položku Validity a jako závorky používá -----BEGIN PRIVACY-ENHANCED MESSAGE-----
a -----END PRIVACY-ENHANCED MESSAGE-----.)