[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
I like the idea but the I-D is hard to read by itself, i.e., the send-cga
I-D is needed to understand things... But this is more a problem about
the organization of the document.
But section 4 is incomplete:
"2. Modifier generation. Generate a Modifier as a random or
pseudorandom 128-bit value. If a public key has not been provided
as an input, generate the Extended Modifier as a 384-bit random or
pseudorandom value. Format the Extended Modifier as a DER-encoded
ASN.1 structure of the type SubjectPublicKeyInfo defined in the
Internet X.509 certificate profile ."
this is underspecified (RSA must be specified) and not clear enough:
IMHO the idea is to get a 384 bit random value and to encode it as
a RSA key in a SubjectPublicKeyInfo DER value. But there is at least
another interpretation... BTW the encoding gives only a static (i.e.,
easy to precompute : 0x 30 42 30 0D 06 09 2A 86 48 86 F7 0D 01 01 01 05 00
03 31 00 <48 octets> but please check :-) prefix.
Finally I am not convinced a type tag is not required for HBA CGAs, i.e.,
today HBA CGAs are not more usable than CGAs...
PS: I have an OpenSSL module for CGAs (with new/free/dup/d2i/i2d and
check/sign/verify). I can send it to who'd like to extend it to HBA
(I'm using the standard BSD licence). It should be easy because if I've
understood the design the multi-prefix extension is an extension field?