[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: generation of private keys
>
> [Juergen] Why not? The CRMF draft MANDATES proof of possession. Can you
> point out to me what does it mean PRETEND. Everybody is able to retrieve
> someone else`s public key and PRETENDS to own the corresponding private
> key. I think that the strength of the mechanism is the point. But I
> would not tend to map this to a certificate extension. This is a concern
> of the certification policy. [Juergen]
CRMF tells WHY POP is manadates. The reason is that at the time when
the document was started, no applications existed that could live
without POP. It MANADATES POP in order to support those applications
that require it without change to application or to certs.
Applications that don't require POP work in all circumstances, but
the can also life with POP guaranteed by the cert. Applications that
need are broken if they use certs for which not pop has been performed
by the CA.
Of course one can always live with a policy based approach:
The user always knows what kind of certs can be used with a
particular application. Then, one might argue that all
cert constraints are superfluous?
PRETEND means pretend, and not more. The user who want
that public key cert PRETENDS to have the corresponding secret.
If the key generation is not done by the CA (in a large sense),
then the user always first pretends to have a secret.
The CA/RA then can use some mechanism to ensure POP.
> >
> > As a consequence, an application must always do that, for
> > example when signing a challenge or document, the certificat
> > (or something equivalent) must be included in the signature.
> >
> [Juergen] As a result, the application plays the role of the trusted
> third party. I think this approach is different from that one described
> in the CRMF draft.
Why does the application play the role of a trusted third party?
The difference betwwen a CA that performs POP and another that doesn't
isn't that big. It is just that, it didn't perform POP. All the other
guarantees, naming plan, identification etc. are still the same.