At 12:13 AM 4/28/96 +0200,
Harald(_dot_)T(_dot_)Alvestrand(_at_)uninett(_dot_)no wrote:
Searching the binary stream for the fixed bytes in the BER that
identify the PGP mechanis formats....
Peter, are you searching for --- BEGIN PGP PUBLIC KEY --- or for
some short tag/length sequence?
in the case of the certificate subjectpublic key
TLV, Im searching for the oid value of the type
which preceeds it (and introduces the next type) in
the stream. This can be a fixed constant by agreement..
instead of searching for rsaEncryption oid value, one
can search for rsaPGPkey oidvalue, fixed in the dod/internet
tree space. Its just a device for those many programmers
who find BER impossible to decode - to locate the required
PGP strings.
If the latter, what is the chance of a false positive?
I dont know. Its a conventient hack to ensure those
who reject BER decoding can get to the data they desire
within the outer packaging.
Thinkg about the case of skpi info
in subjectPublicKey field, this oid trick sounds fine. The outer
DER-transferred certificate bytes are signed/protected
anyway. Perhaps in the message elements, there would be a problem, if
the S/MIME msg did not itself protect itself and the wrapping of
the PGP elements, and the oid bindings to be used by
the (simplistic) bit-decoder. Contrary case would allow attackers
to substitute the bytes upon which the bit-decoder is
based, faciliating security failures, and thereby
interfering with the messaging channel.
Not sure where to go with this. Using S/MIME to
tunnel PGP is the basic idea. Classic case of protocol/format
conversion technology, I suspect, with some new edges concerned
with security implications.
Harald A