Subject: [Asrg] Patent Wednesday

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 16 Mar 2005 12:40:30 -0800

Since its patent Wednesday here is a patent that I recently filed that may
interest the group:

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fneta
html%2FPTO%2Fsearch-adv.html&r=2&p=1&f=G&l=50&d=PG01&S1=hallam-baker.IN.&OS=
in/hallam-baker&RS=IN/hallam-baker

The key claim is a means of accrediting end users that does not require
identity accreditation.

Imagine that you could buy a USB key fob token for approx $40 that could be
plugged into an email server to provide a source of accredited email
signatures. Each time an email message is signed the token increments a
counter, the counter is incorporated within the body of the signature. This
means that provided the integrity of the token is trustworthy the receipient
of a message can determine how many messages the sender has signed.

If a source of time is available the scheme can be extended to create a
'velocity indicator', this does not need to be trusted provided that the
recipients have access to a source of trusted time. It is also possible to
extend the scheme to enforce more general email sending policies.

The significant point here is that it is possible to demonstrate compliance
with the email sending policy without the need to authenticate the identity
of the sender. It is possible for an anonymous sender to use the scheme.

ObLegal: This message does not confer a right of use. All rights explicitly
reserved.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 16 Mar 2005 14:19:52 -0800 (PST)

Interesting idea. Unclear on the counter thing though. Are you inclduding
this on the "key" clear text? If yes, then user can easily temper with it
and change so the counter data can not be trusted. If its not clear text,
and is signed, then its necessary to include private key with user program
and its the same problem as resourcefull hacker would find how to change
it by reverse-engineering.

So if the counter can not be trusted, all we have is SecureID clone for
email but that makes it possible for bad guy to have bought this "key"
anonymously and start using it to send bad emails. The only way to stop
this would be with revocation and with real-time system that can monitor
requests for revocation (which must be done for every message) and begin
to respond negatively if they are too many (way beyond what was in the
counter...).

Am I on the right track here on how it will have to be used?

-- 
William Leibzon
Elan Networks
[email-masked]