Ned Freed writes:
Dunno how you intend to prevent their transmission -- the whole point of
this
stuff is that it has to behave reasonably even when under deliberate
attack.
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.
I don't think a warning in the spec is sufficient. Again, most users will
never read that.
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 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.
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?
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.
Phil