> That's a red herring. It happens to use X.509 as its preferred bit-bagging
> format for public keys, but that's about it. People use self-signed certs,
> certs from unknown CAs [0], etc etc, and you don't need certs at all if you
> don't need them, <blatant self-promotion>I've just done an RFC draft that uses
> shared secret keys for mutual authentication of client and server, with no
> need for certificates of any kind</blatant self-promotion>, so the use of
> certs, and in particular a hierarchical PKI, is merely an optional extra.
> It's no more required in SSL than it is in SSHv2.
the pk-init draft for kerberos allows public keys .... allowing both cert & cert-less implementation
<blatant aads-promotion> the scenario allows for public key registration in lieu of shared secret registration. the scenario is that r/o access, divulging, sniffing, etc doesn't result in compromise.
in the token form .... http://www.garlic.com/~lynn/index.html#aadsstraw http://www.asuretee.com/
the key-pair is gen'ed in the chip and never leaves the chip.
as part of 3-factor authentication * something you have * something you know * something you are
the chip in the token purely provides "something you have" authentication ... and the digital signature done by the token is purely to prove that you have that particular token. It doesn't prove who you are, it just proves that you have a specific (extremely difficult to counterfeit) token as part of "something you have" authentication.
if the token is augmented with a pin/password for its correct operation, then there can be 2-factor authentication. It doesn't involved shared-secrets since the pin/password is purely between the person and the hardware token.
The business process validates that the token is of the type requiring PIN and/or biometric for correct operation.
The ecdsa digital signature authentication protocol for kerberos, radius, x9.59 for all retail financial transactions, or ssh can be identical regardless of the integrity level.
The ecdsa digital signature authentication protocol can be ubiquitous regardless of the authentication integrity level required.
The business process to meet integrity requirements then can require sofware key-pair or hardware token key-pair, the level of integrity of the hardware token, and/or the operational characteristics of the hardware token (no-pin, pin, biometrics, etc) w/o changing the protocol.
If the protocol is independent of the business process integrity issue then either the business and/or the end-user may be able to having personal choice about the level of integrity required. Furthermore, the person might even have personal choice whether they need a unique token per security environment, a single token for all security environment, and/or a small number of tokens selectively applied to different security environments
the digital signature has nothing at all to do directly with the person, it is purely related to demonstrating the possession of the token (as part of something you have authentication) and possibly the integrity level of the token.
The issue of the authentication protocol is getting the bits and bytes for transmission correct but doesn't normally say what it means ... i.e. secret, shared-secret, one factor authentication, two-factor authentication, something you have authentication, something you know authentication, etc. ... although frequently the protocol is envisioned to be a specific implementation of a specific kind of authentication and trust/integrity level.
recent token discussions
http://www.garlic.com/~lynn/2003i.html#1 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#2 Two-factor authentication with SSH?
http://www.garlic.com/~lynn/2003i.html#35 electronic-ID and key-generation
http://www.garlic.com/~lynn/2003i.html#36 electronic-ID and key-generation
older token discussions
http://www.garlic.com/~lynn/aadsm10.htm#bio6 biometrics
http://www.garlic.com/~lynn/aadsm10.htm#keygen2 Welome to the Internet, here's your private key
http://www.garlic.com/~lynn/aadsm11.htm#5 Meaning of Non-repudiation
http://www.garlic.com/~lynn/aadsm12.htm#24 Interests of online banks and their users [was Re: Cryptogram: Palladium Only for DRM]
http://www.garlic.com/~lynn/aadsm7.htm#rhose12 when a fraud is a sale, Re: Rubber hose attack
http://www.garlic.com/~lynn/aepay10.htm#65 eBay Customers Targetted by Credit Card Scam
http://www.garlic.com/~lynn/2000f.html#65 Cryptogram Newsletter is off the wall?
http://www.garlic.com/~lynn/2001c.html#39 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#1 distributed authentication
http://www.garlic.com/~lynn/2001g.html#11 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001j.html#52 Are client certificates really secure?
http://www.garlic.com/~lynn/2001k.html#61 I-net banking security
http://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#18 Opinion on smartcard security requested
http://www.garlic.com/~lynn/2002e.html#36 Crypting with Fingerprints ?
http://www.garlic.com/~lynn/2002h.html#41 Biometric authentication for intranet websites?
http://www.garlic.com/~lynn/2002i.html#65 privileged IDs and non-privileged IDs
http://www.garlic.com/~lynn/2002n.html#30 Help! Good protocol for national ID card?
http://www.garlic.com/~lynn/2002o.html#57 Certificate Authority: Industry vs. Government
</blatent aads promotion>
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
