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

Preliminary comment skip draft 03



Hello Ashar, all,

I just received the new skip draft (03), and did one quick reading. I was
pleased to see the changes and adaptions. (03) looks really close to 'IT'
for me.

I am mostly happy with it, only the certificate discovery seems botched. 
Assume I send a request for certificates partaining to a certain
master Id, and want at the same time to provide some of my own certificates,
and the corresponding master ID. The draft explicitly states that this is 
possible. But there is only one master ID field. Is there a master ID stored
within each certificate? [Hmm. Might be.]
Something there is ambigous, or perhaps plain wrong.

Do you expect all future certificates to be shorter than 256 bytes? As
indicated by CERT-LENGTH. And there are more things that I already mentioned
in my comments to (02).

I will do some careful reading in the next few days, and give you a more
exhaustive reply by Monday or so.

Friendly greetings,

	       Germano



infamous second thoughts:

p.s. concerning the usage of stream ciphers: We saw in Atlanta that a cipher
with speed comparable to RC4 is needed for encryption of live video. The
draft mentions RC4 as possible 'Crypt Alg', but gives no references as how
the following header is to be composed. Perhaps this, and the MI issue
should be discussed somewhere? On the other hand I have been informed that 
there are legal issues with writing an RC4 transform draft. The same 
probably is true in this case. If yes, I just want to give the following
input. It might allow us to synchronize implemenation efforts, without 
stumbling over ITAR and 'cleanroom':
                                         encrypted part
+---------------+-----------------------+====+========================+
|32-bit SKIP SPI|64-bit MI network order|data|8bit next protocol field|
+---------------+-----------------------+====+========================+
where MI is the number of bytes that were already encrypted with the 
current Kp. 

p.p.s RFC1851 (3DES) does not appear in (03). Why? See my comments to 
draft (02).