"Hoyt L. Kesterson II" wrote:
> i don't understand. maybe i am too simpleminded. i suggest that all
[...]
> suspect the same pop is robust enough to prove right to revoke.
No, probably I am talking about something that has got already a solution,
anyway, I have not fully read the proposed rfc2510bis, anyway the pop is
left without specification. The section 2.3 describes POP of a private
key, while section 3.3.9 describe a revocation request content.
As described there:
RevReqContent ::= SEQUENCE OF RevDetails
RevDetails ::= SEQUENCE {
certDetails CertTemplate,
-- allows requester to specify as much as they can about
-- the cert. for which revocation is requested
-- (e.g., for cases in which serialNumber is not available)
crlEntryDetails Extensions OPTIONAL
-- requested crlEntryExtensions
}
Where is any POP in this structure ? Is this the right request to be
used by a client to ask for revokation ?
In section 3.3.10 there is the request response description, wich, to
me, suffers from the same problems -- it seems as the control it too
delegated to external POP. I am probably wrong, I did not had the chance
to read through the whole document -- any help ?
> if someone other than the owner can demonstrate pop, then it doesn't
> matter who issues the revocation request-the certificate should be
> revoked.
Perfectly right. If the reported revocation req/resp are the right one
to be used, I think it could be an help to develop a different protocol
extending the proposed structure allowing for extended control over
the whole revokation process ( expecially for the client point of view).
Thanks to everyone for comments sent and future.
--
C'you,
Massimiliano Pala
--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] madwolf@xxxxxxxxxx
madwolf@xxxxxxxxxxxxxxx
http://www.openca.org Tel.: +39 (0)59 270 094
http://openca.sourceforge.net Mobile: +39 (0)347 7222 365Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature