> According to the current PEM/MIME what is the
> recommended interaction between a user and a PCA for
> getting the latest CRL? In RFC 1424, I would compose a
> CRL-RETRIEVAL-REQUEST with the Issuer: field set to the
> issuer's name. But the <id> for the
> application/key-request has no "DN only" form like this.
> How would I request the CRL for the TIS PCA, for
> example?
> What you would do is send an application/key-request message
> with the Issuer field only to set to an appropriate <id>
> value. For example,
>
> Content-Type: application/key-request
>
> Issuer: DN, <keyid>, <distinguished name of issuer>
>
> An obvious question to ask is, "what do I set <keyid> to,
> since it must be non-null?"
>
> The answer is that you use the key identifier for the public
> key of the issuer identified by the distinguished name
> specified in the ISSUER field that signed the CRL you wish to
> retrieve. Boy is that a mouthful.
Let met ask this way: Suppose I receive a PEM/MIME signed
message from someone and they also include an
application/key-data with a <certchain>. (And suppose the
sender has not included the optional <crl> fields.) Where do I
find the <keyid> for the issuers to request the CRLs ? It is not
in the <certchain>. Am I missing an interchange that has to
happen somewhere?
You are exactly right, there is an interchange that must occur
somewhere. The missing interchange is the one that binds the name form
and key id to a public key/private key pair.
You are correct the specification does not allow for the explicit
inclusion of this binding in the certificate or crl chain. However, I
would expect a server responding to an application/key-request message
to want to return all relevant information to a client. Thus, I would
expect a server to return two application/key-data body parts to the
client, one with the desired chain and one (or more) with the necessary
bindings.
If you want to suggest that this is "ugly" and that we should have
explicitly included all relevant information at all times, my response
is I hear you. However, a principal objective was to provide building
blocks that can be utilized in straightforward ways to realize all the
currently visible features and hopefully features we haven't thought of
yet. In other words, what we propose is a design choice based on our
experience building PEM and MIME systems. We're not claiming it's
perfect, but in the spirit of "rough consensus and running code", it
works.
Jim
binza12hTs9zg.bin
Description: application/signature