jsdsi-users

[Jsdsi-users] Specific Tag

[Luis P. <lp...@ne...>]

Guillermo,

Taking Sean's ideia u can also try:
	1 - (tag (index (* range numeric g 0 le 2))) for an index = 2;
	2 - (tag (index (* range numeric g 0 le 6))) for an index = 6;
Then, when u intersect '1' with '2' the result will be 1.

U can achieve this tags by doing: new SimpleTag("index", new ExprTag[] {new
RangeTag("numeric", "2", false, "0", true)}).

I think that u can also achieve your tag using just jsdsi.

	-- Luis Pedro 

Re: [Jsdsi-users] Specific Tag

[Guillermo N. <gna...@cc...>]

Hi,

apologies for not writing before I've been very busy these weeks. 

First of all thanks to all of you for your answers and suggestions. I
will try to explain a little bit more the tag I am using and the
meaning of the hash.

The main idea comes from micropayments as hashed chains. Were we may
have a hash chain like this: h^n(m),...,h^1(m),h^0(m)

What I do is to consider each element of the chain as an
authorization, thus a tag. I consider each element as: 
(id, index, val): (id,n,h^n(m)),...,(id,1,h^1(m)), (id,0,h^0(m)).

To intersect them, imagine I have (id, 2, h^2(m)) and (id, 3,
h^3(m)). The intersection should be (id,3,h^3(m)), because:

1- id's are iqual.
2- 3 is greater or equal to 2
3- and h^3(m)=h(h^2(m))

As you told me I can achieve points 1 and 2 using existing jsdsi tags,
but I think that for point three I need to redefine the intersection
function.  That is why I first though about extending
jsdsi.Tag. Another possibility is to avoid evaluating point 3 in the
intersection, but then the hash verification has to be done somewhere
else.

I am sorry I've my previous post were not very clear, and thanks again
for your interest. As I told you I've been quite busy, if I get
something out of this I will let you now.

Guillermo

Re: [Jsdsi-users] Specific Tag

[Sameer A. <aj...@cs...>]

> As you told me I can achieve points 1 and 2 using existing jsdsi tags,
> but I think that for point three I need to redefine the intersection
> function.  That is why I first though about extending
> jsdsi.Tag. Another possibility is to avoid evaluating point 3 in the
> intersection, but then the hash verification has to be done somewhere
> else.

I think checking the hash chain somewhere else makes sense.  The ID is
enough to uniquely identify a hash chain, and the index ensures proper
ordering, so together they are enough for the Prover to build the
certificate chain.  Assuming the certificates were created correctly, then
the hash chain should also be correct.  Of course, the Verifier will need
to check that this is in fact true!

Also, I don't think "h2 = h(h1)" is really in the spirit of tag
"intersection" -- contrast with the intersection rules for sets, ranges,
prefixes, etc, which are more intuitive.

I actually think hash chains ought to be a separate primitive in JSDSI. 
Hash chains are useful to create certificate revocation and validation
lists and trees, and JSDSI currently has no support for them.  A long time
ago I proposed a format for hash chains to the SPKI mailing list; perhaps
I should dig that up.  You might search the SPKI mailing list archives for
mention of hash chains or validation trees.

Sameer

Re: [Jsdsi-users] Specific Tag

[Guillermo N. <gna...@cc...>]

Sameer Ajmani <aj...@cs...> writes:
> I think checking the hash chain somewhere else makes sense.  The ID is
> enough to uniquely identify a hash chain, and the index ensures proper
> ordering, so together they are enough for the Prover to build the
> certificate chain.  Assuming the certificates were created correctly, then
> the hash chain should also be correct.  Of course, the Verifier will need
> to check that this is in fact true!
>
> Also, I don't think "h2 = h(h1)" is really in the spirit of tag
> "intersection" -- contrast with the intersection rules for sets, ranges,
> prefixes, etc, which are more intuitive.

yes, that's true, it is by no means intuitive :) I am currently doing
what you outline. I put the hash value into the comment of the
certificate --(by the way, is there any way that I can put the hash
into the "tag" so it is ignored by the intersection algorithm?)--, and
the verifier stores all the hashes in order to check them later. 

I use the hash as some sort of authorization token I just though it
may be easier if the intersection could ensure the validity of the
hash. But, in fact, is not that "nconfortable to check it later.

> I actually think hash chains ought to be a separate primitive in JSDSI. 
> Hash chains are useful to create certificate revocation and validation
> lists and trees, and JSDSI currently has no support for them.  A long time
> ago I proposed a format for hash chains to the SPKI mailing list; perhaps
> I should dig that up.  You might search the SPKI mailing list archives for
> mention of hash chains or validation trees.

Thanks, I couldn't find any hash chains or validation trees references
in the archives at a first search. I'll try to look at them closer. 

Thanks for the advice.

Guillermo

Re: [Jsdsi-users] Specific Tag

[Sean R. <sra...@ae...>]

On Wed, 2004-05-12 at 17:51, Guillermo Navarro wrote:
> Sameer Ajmani <aj...@cs...> writes:
> > I think checking the hash chain somewhere else makes sense.  The ID is
> > enough to uniquely identify a hash chain, and the index ensures proper
> > ordering, so together they are enough for the Prover to build the
> > certificate chain.  Assuming the certificates were created correctly, then
> > the hash chain should also be correct.  Of course, the Verifier will need
> > to check that this is in fact true!
> >
> > Also, I don't think "h2 = h(h1)" is really in the spirit of tag
> > "intersection" -- contrast with the intersection rules for sets, ranges,
> > prefixes, etc, which are more intuitive.
> 
> yes, that's true, it is by no means intuitive :) I am currently doing
> what you outline. I put the hash value into the comment of the
> certificate -

> -(by the way, is there any way that I can put the hash
> into the "tag" so it is ignored by the intersection algorithm?)
Nope. I think that putting them in the comment is perfectly allowable
though.

> --, and
> the verifier stores all the hashes in order to check them later. 
> 
> I use the hash as some sort of authorization token I just though it
> may be easier if the intersection could ensure the validity of the
> hash. But, in fact, is not that "nconfortable to check it later.
> 
> > I actually think hash chains ought to be a separate primitive in JSDSI. 
> > Hash chains are useful to create certificate revocation and validation
> > lists and trees, and JSDSI currently has no support for them.  A long time
> > ago I proposed a format for hash chains to the SPKI mailing list; perhaps
> > I should dig that up.  You might search the SPKI mailing list archives for
> > mention of hash chains or validation trees.
> 
> Thanks, I couldn't find any hash chains or validation trees references
> in the archives at a first search. I'll try to look at them closer. 
Just to clarify... Sameer is talking of the SPKI mailing list, not
JSDSI.

> Thanks for the advice.
> 
> Guillermo
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Jsdsi-users mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-users
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-users] Specific Tag

[Guillermo N. <gna...@cc...>]

Sean Radford <sra...@ae...> writes:
>> -(by the way, is there any way that I can put the hash
>> into the "tag" so it is ignored by the intersection algorithm?)
> Nope. I think that putting them in the comment is perfectly allowable
> though.

Ok, thanks.

>> > Hash chains are useful to create certificate revocation and validation
>> > lists and trees, and JSDSI currently has no support for them.  A long time
>> > ago I proposed a format for hash chains to the SPKI mailing list; perhaps
>> > I should dig that up.  You might search the SPKI mailing list archives for
>> > mention of hash chains or validation trees.
>> 
>> Thanks, I couldn't find any hash chains or validation trees references
>> in the archives at a first search. I'll try to look at them closer. 
> Just to clarify... Sameer is talking of the SPKI mailing list, not
> JSDSI.

Thanks, that's what I though. I searched:

http://www.sandelman.ottawa.on.ca/spki/ 
http://groups.yahoo.com/group/spki/messages

guillermo

Re: [Jsdsi-users] Specific Tag

[Sameer A. <aj...@cs...>]

I have these messages saved in my personal mail folders.  Would it be
sueful to post them online somewhere?  Does anyone know an easy way to
extract messages into HTML from mbox format?

Sameer

>>> Thanks, I couldn't find any hash chains or validation trees
>>> references in the archives at a first search. I'll try to look at
>>> them closer.
>> Just to clarify... Sameer is talking of the SPKI mailing list, not
>> JSDSI.
>
> Thanks, that's what I though. I searched:
>
> http://www.sandelman.ottawa.on.ca/spki/
> http://groups.yahoo.com/group/spki/messages
>
> guillermo
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Jsdsi-users mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-users


http://ajmani.net