-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thomas Roessler wrote:
On 1999-07-07 02:38:43 -0700, Will Price wrote:
High level biometric authentication methods that a particular
vendor (in this case Network Associates) chooses to implement are
well beyond the scope of this list.
From the context, it should have been obvious to you that by
"fingerprint" I meant "key fingerprint", and not any biometric
authentication methods your company may or may not choose to
implement.
Yes, it was obvious. You're not seeing what I mean by biometric.
The word list is a feature we implemented to provide better biometric
properties for key fingerprint authentication.
Technical documentation and mappings for the word lists are
published in the docs for PGP where they belong. Not in this
group.
Sorry, Will, this word mapping _is_ an interchange format for
OpenPGP key properties, so it _does_ belong on this list and into
an (at least informational) Internet RFC. After all, there is a
reason behind having a well-defined key fingerprint displayed to
and exchanged by users, isn't it?
I could see a case for documenting the word list we developed into an
informational RFC with no relation to this working group. I'm sure
we'd be happy to see that happen. However, the feature is a
biometric authentication method that has no relation to the OpenPGP
data formats. Saying that this should have gone through OpenPGP in
the first place is like saying the PGPkeys GUI and whether RSA keys
are silver or gold should go through OpenPGP. In theory, it's an
interesting concept to write a standard for such things so that
everybody using any implementation knows that RSA keys are silver,
but that's not the role of the IETF. We still display display the
hex fingerprint format. Please feel free to write an informational
RFC using the list provided in our documentation.
Concerning the SDAs, having a platform-independent marker string
which indicates where the ciphertext begins shouldn't be such a
great pain, and it would enable independent implementations running
on other platforms than the one intended by the SDA's sender to
extract the ciphertext. (I'm assuming that you don't use a
proprietary format for _all_ of the SDA.)
The SDA format will change and is very fluid even now. SDAs are not
intended to be sent from one user to another like a PGP message. In
many cases, that would violate export controls and introduces other
concerns like viruses and trojan horses, and can't be signed. SDAs
are a specific customer request we received many times for things
like placing conventionally encrypted items in a CD-ROM package.
They don't use any public keys, and are not an interchange format.
Any other OpenPGP implementation can feel free to implement their own
SDAs using their own format. Encouraging standardization of such a
format implies that the format is a wise way to exchange encrypted
data over the wire when that is clearly not the case. OpenPGP is the
solution for exchanging encrypted data on the wire.
- -- Will
Will Price, Architect/Sr. Mgr., PGP Client Products
Total Network Security Division
Network Associates, Inc.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.1
iQA/AwUBN4M0d6y7FkvPc+xMEQI1JwCfX80qkakGMXiG6vCLuasvHlOv3LUAn3IT
PyiWpIXY27Brn7TuTnQnuWo4
=HLuo
-----END PGP SIGNATURE-----