[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SDSI syntax

>   There's another issue with the "canonical" encoding in SDSI - it's
>not possible to perform signature generation or signature verification
>in single pass through the SDSI object. This is because the verbatim
>representation includes a length field at the beginning of the

I also started to worry about that given the propensity of the IETF for 
deciding that everything is a nail when given a particular hammer they like.

Since we are merely using the canonical form for developing the hash value we 
could use a self describing length format. After all there is no need for the 
canonical form to be easy to convert from. It is merely the input to the hash 
function. Plus since we are likely to be using an MD4 type digest where there is 
a compressor fucntion and a chaining mechanism this does not need to introduce 
inefficiency. We can perform the encoding step as we construct the values for 
the compression block.

I would suggest we use the expansion 00 -> 00 00 and then use the sequence 
00 FF as an end of block marker. That can be generated in a single pass by an 
FSR without any backtracking. Then we are OK even if someone later comes along 
with some derranged scheme which involves large and unwieldy chunks of text.

Compared to the time complexity of MD5/SHA I don't think we need to worry about 
such a transformation. On the other hand space complexity worries me greatly. I 
would like to be able to implement many crypto functions on smartcards with 
crypto processors where memory may be at an extreeme premium.

>  But I'm disappointed that the only thing we're talking about is the
>syntax. The semantics of SDSI bring up very large questions, and I can't
>say I'm fully satisfied with the design

My experience is that it is often necessary to discuss syntax before people
can move to discussion of semantics simply because they need a medium to 
express their ideas 

I think that the role of SDSI is potentialy simliar to that played by iKP 
in the credit card format wars. The point of iKP was not the suggestion itself 
but the fact that it solved enough of the problem to serve as a paradigm to 
which all other proposals could be compared. Indeed there was no real technical 
value in 1KP or 2KP in that Mastercard was intending from the start to do 3KP. 
On the other hand these did play a critical role in breaking down the previously 
established mindset. 

Ralphs's point is well made in that maybe the semantics of SDSI are not quite 
what we would like. That is something that we need to discuss further. It is 
likely that the discussion will reveal many of the unspoken assumptions which 
affect our view of the problem. It may be logical to describe systems in terms 
of requrements which lead to an architecture which is realised in an 
implementation but the mind often seems to work better in reverse. Experience of 
use informs architecture and requirements. Often it is better to ask "what 
problems can I solve with this technology" than atteempt to find a solution to 
previously laid down assumptions.