[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Polling in CMP
Hi Magnus, Gareth,
A quick glance seems the proposal is inline with the original discussion.
However,
I would like to expand the scope of polling a little bit. One of the other
problems
we have been dealing with is that issuance of certificates sometimes
require
a back and forth question & answer session between the end entity and the
server
for identity authentication. The current interoperable subset of the CMP
protocol assumes
(a) all the information needed by the server is in the original request or
(b) the server
does out of band verification if information needed is not sufficient.
I believe this requirement is generic enough to require interoperable
support
and should go into the CMP protocol. Based on the use of the proposed CMP
poll request & response, it looks like a good choice. Would like to hear
your
thoughts......
regards
Amit
Magnus Nystrom <magnus@xxxxxxxxxxxxxxx> on 09/06/2001 07:19:28 AM
Please respond to Magnus Nystr
öm <magnus@xxxxxxxx>
To: ietf-pkix@xxxxxxx
cc: "Richards, Gareth" <GRichards@xxxxxxxxxxxxxxx> (bcc: Amit Kapoor/Certicom)
Subject: Polling in CMP
All,
Going back to a topic discussed earlier this year, and after
discussions with various individuals at the recent IETF in London, we
would like to propose the attached simple extension to CMP to handle
polling. The reason for this proposal is as stated previously - we
feel that a protocol which specifies a "wait - come back later"
server status also should specify how a client should poll the server,
rather than deferring this to transport protocols.
Assume that the CMP enrollment is taking place in a browser script and
the browser may be terminated before the polling is complete. Then a
way of saving state and continuing the polling at a later date is
needed. If the polling is done in CMP then this is possible by
reissuing the request or whatever but if it is done by the transport
layer then it does not seem clear how this is going to be done.
Thanks to Amit Kapoor for the original proposal regarding these
messages.
BR,
-- Magnus
Magnus Nystrom
RSA Security
--------------------------------------------------------------------------
pollReq [25] PollReqContent
pollRep [26] PollRepContent
PollRepContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER,
checkAfter INTEGER, -- time in seconds
reason [0] PKIFreeText OPTIONAL
}
PollReqContent ::= SEQUENCE OF SEQUENCE {
certReqId INTEGER
}
1. It is assumed that multiple certConf messages can be sent during
the transaction. There will be one sent in response to each ip, cp or kup
containing a CertStatus for each approved certificate. If a
single certConf must be sent for the transaction then it is possible that the
confirmWaitTime (rfc2510bis section 3.1.1.2) of the first certificate will have
expired before the second cert pickup has take place.
2. In response to an ip, cp or kup message, an EE will send a certConf for all
approved certificates and following the ack, a pollReq for all pending
certificates.
2. In respose to a pollReq, a CA/RA will return a ip, cp or kup if one or more
of the pending certificates is ready otherwise it will return a pollRep.
3. If the EE receives a pollRep in return, it will wait for at least the lowest
checkAfter value before sending another pollReq.
4. If an ip, cp or kup is received in reply to a pollReq then it will be treated
in
the same way as the initial response.
Start
|
|
\/
Send ir
|
| ip
|
\/
Check status
of of returned
<----------------------------------|
certs.
|
|
|
|----------------------------->|<-----------------------|
|
| | |
|
| \/ |
|
approved waiting
|
Add to conf list <---------- Check CertResponse --------> Add to pending list
|
/\
|
conf list / \Empty conf list
|
/ \ ip
|
/ \
--------------------------------|
Empty pending / \ |
list / \ | pRep
End <--------- Send certConf Send pReq-------------- Wait
| /\ /\ |
| | | |
------------------- -------------------
Pending list Wait
In the following exchange, the end entity is enroling for two certificates in
one request.
Step End Entity PKI
-------------------------------------------------------------------
1 Format ir
2 -> ir ->
3 Handle ir
4 Manual intervention is
required for both certs.
5 <- ip <-
6 Process ip
7 Format pReq
8 -> pReq ->
9 Check status of certificate requests
10 Certificates not ready
11 Format pRep
12 <- pRep <-
13 Wait
14 Format pReq
15 -> pReq ->
16 Check status of certificate requests
17 One certificate is ready
18 Format ip
19 <- ip <-
20 Handle ip
21 Format certConf
22 -> certConf ->
23 Handle certConf
24 Format ack
25 <- pkiConf <-
26 Format pReq
27 -> pReq ->
28 Check status of certificate
29 Certificate is ready
30 Format ip
31 <- ip <-
31 Handle ip
32 Format certConf
33 -> certConf ->
34 Handle certConf
35 Format ack
36 <- pkiConf <-