Re: [hiprg] draft-zhang-hip-hierarchical-parameter-00: Includinghieararchy in HIT generation

["Henderson, Thomas R" <[e-mail]>]

 

> -----Original Message-----
> From: Tobias Heer [mailto:[e-mail]] 
> Sent: Tuesday, July 28, 2009 6:02 AM
> To: [e-mail]; Xu Xiaohu
> Cc: [e-mail]
> Subject: [hiprg] draft-zhang-hip-hierarchical-parameter-00: 
> Includinghieararchy in HIT generation
> 
> Hi!
> 
> I just wanted to clarify my comment in the HIPRG meeting on 
> including  
> the hierarchy in the HIT creation process. I think it would 
> be good to  
> have the hierarchy information in the HIT creation process 
> because the  
> hierarchy will be bound to the HIT itself.
> 
> Below I briefly sketched a possible way of including it without  
> revealing the hierarchy to all hosts.
> 
> HIT generation could work like this:
> 
> 1. Pick random secret X
> 
> 2. H(Hierarchy, X) => HTag
> 
> 3. H(PubKey, ..., HTag) => HIT (Orchid)
> 
> --> Only use LTag if you do not want to reveal hierarchy.
> --> Use hierarchy and X if you want to reveal the hierarchy.

Hi Tobias,

I recently had a chance to listen to the audio archive of the meeting
and I'm reviewing the mail now.  Can you explain in more detail what is
the use case for what you are proposing?  I thought that the draft was
mainly concerned with having publicly revealed hierarchies so that
reverse lookups could exploit hierarchy.  In your proposal above, for
the observer who knows X, how does such observer retrieve hierarchy
bits, given the HIT, HTag, and X?

Also, I am not sure you can claim that the result from your above is a
HIT, because according to RFC4843 and 5201, a HIT is formed without
these HTags.  In particular, the HIT would no longer be able to be
associated to the key, for an observer who does not know the magic HTag
to apply. 

Tom