Cryptography Reference
In-Depth Information
Certificate Generation with User-Provided Keys
Alice
CA
generate
k
pr
,
A
,
k
pub
,
A
RQST
(
k
pub
,
A
,
ID
A
)
−−−−−−−−−−−−→
verify
ID
A
s
A
= sig
k
pr
,
CA
(
k
pub
,
A
,
ID
A
)
Cert
A
=[(
k
pub
,
A
,
ID
A
)
,
s
A
]
Cert
A
←−−−−−−−−−−−−
From a security point of view, the first transaction is crucial. It must be assured
that Alice's message (
k
pub
,
A
,
ID
A
) is sent via an authenticated channel. Otherwise,
Oscar could request a certificate in Alice's name.
In practice it is often advantageous that the CA not only signs the public keys
but also generates the public-private key pairs for each user. In this case, a basic
protocol looks like this:
Certificate Generation with CA-Generated Keys
Alice
CA
RQST
(
ID
A
)
−−−−−−−−−−−−→
request certificate
verify
ID
A
generate
k
pr
,
A
,
k
pub
,
A
s
A
= sig
k
pr
,
CA
(
k
pub
,
A
,
ID
A
)
Cert
A
=[(
k
pub
,
A
,
ID
A
)
,
s
A
]
Cert
A
,
k
pr
,
A
←−−−−−−−−−−−−
For the first transmission, an authenticated channel is needed. In other words:
The CA must be assured that it is really Alice who is requesting a certificate, and
not Oscar who is requesting a certificate in Alice's name. Even more sensitive is the
second transmission consisting of (Cert
A
,
k
pr
,
A
). Because the private key is being
sent here, not only an authenticated but a secure channel is required. In practice,
this could be a certificate delivered by mail on a CD-ROM.
Before we discuss CAs in more detail, let's have a look at the DHKE which is
protected with certificates:
