The binding of specific keys to specific functions is quite outside the
range of all these specifications. This isn't to say that such bindings are
unimportant -- they are extremely important -- but they just aren't part
of current proposals.
I don't suggest not transmitting them. As Jeff Thomson pointed out, they
can be transmitted as application/pemkey-data, verified, and kept for later
use.
As the document points out, putting the key/name form in every signed
message creates the risk of receiving an incorect key/name form pair.
"... it may be possible for a malicious originator to assert an identifier
that accords the originator unauthorized privileges." So I ask again, why
allow this? Limit communication of the key/name form association to
application/pemkey-data with the understanding that the assertion has to be
verified there.
Hmm. Well, I guess I don't understand what you're talking about here. This
discussion started with a criticism of some of the working in the
specification. Now it seems to have become a request for some kind of protocol
change.
We're in last call. As such, if you think a protocol change is needed, I think
you need to write up specifically what you're asking for, why you think it is a
good idea, and why you think it is essential that this change be made at this
late date.
A good way to address this might be to take the example PEM messages
on pages 21 and 23 (in my copy) of rfc1421 and map them to MIME-PEM and
post
THOSE examples. That would help translate the functionality offered by
rfc1421 to that offered by MIME-PEM. Anyone else agree?
This sounds fine to me, and I have no problem with adding such descriptive
examples and prose to the documents at some point in the future. However,
since
I'm not the editor of these documents right now, I cannot commit to getting
such an example in place in this iteration of the specifications. Moreover,
if
there's a timing problem, I don't think the benefits of adding such an
example
merit any more delay in the advancement of these documents.
You don't think discussion of one of the supported pemkey-data forms merits
discussion right now? I do.
I don't. Again, we're in last call. This is not an appropriate time to propose
major extensions and radical changes, which as near as I can tell is what
you're proposing here, unless such changes are needed to correct major mistakes
in the protocol providing the service it purports to provide.
I wouldn't have thought providing two more examples would take very long. I
understand the authors are pressed for time responding to the message
traffic in this mailing list. But I believe some good examples will reduce
the confusion and associated messages. I was also surprised the original
spec did not contain an example with a cert chain since that would provide a
mapping from rfc1421 to MIME-PEM.
This is not mine to say since I'm not the editor of the specifications any
more. It is up to Jim and Sandy to assess this request (which has now expanded
from a request for an example showing how key data can be exchanged in parallel
with a signed message to a request that shows the specific use of RFC1421-style
cert chains in conjunction with MIME/PEM) and see if there's time to address
it.
Speaking from prior experience, it isn't always as easy as it looks to add such
things to documents.
Now I have to ask my question in a less direct manner than if I had a
signed encrypted MIME message with cert chain example to reference.
In such a case, is the application/pemkey-data (with the cert chain) in the
same multipart as the signed encrypted message?ge? If not, what associates
the cert chain with the multipart containing the message the originator
signed?
It can be within the signed material if you want it to be, although I figure
that isn't an especially useful way to do it. I would expect to find it
in a separate part of a multipart message where the signed object is also
one of the parts. The key data could appearbefore the signed material
or after -- it really doesn't matter.
As for what associates the two, the answer is that nothing in the message
structure associates the two. They could be in separate messages sent months or
years apart, or sent by completely independent agents, for that matter, so it
doesn't make sense to bind them to each other in any way in the message
structure.
The association is implicit in the fact that the cert chain signs the same
certificate that appears in the signed object. This is the only association
that is meaningful. You put whatever cert chains make sense to you in your
local database (either system-wide or personal or group-wide or whatever) and
then you check the certs in signed messages against that data. The cert chain
could have arrived months before, in the signed message, or months later in
response to a request you make using some request mechanism (X.500 or a
MIME/PEM key request or whatever). The idea here is to leave the mechanism
fairly open, because no one mechanism is suitable for all applications.
My interpretation of the document is that they are separate. Am I correct?
I wopuld have thought they would be easier to handle in one piece.
Not at all -- it is actually easier if they are separate, in my opinion (I
speak as a MIME implementor here.) This way I know what's in the part without
having to parse it, and I can call up the appropriate service.
It might be possible to add a field to the header of the signature data that
references the MIME content-id of the part containing the cert chain, assuming
there is one. However, given the liklihood that cert chains will arrive
separately much of the time I question the general utility of such a mechanism.
We can always add it in the future if implementation find it to be useful...
that's the beauty of the MIME framework approach to this stuff!
Ned