[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPKI Starting Point?
>
>
> Taking the idea of spki as whois++/rfc822 a step further, here is a
> bare-bones (unstuffed?) straw-man with the basic additional fields.
>
> Sig-Algorithm: <name of algorithm being used, eg. RSAwithMD5>
> Sig-NotBefore: <Date>
> Sig-NotAfter: <Date>
> Sig-Signer: <URI identifying signing key>
> Sig-Signature: <base64 encoding of the result of applying
> Sig-Algorithm to all fields in this template,
> with all multi-line values treated as if the
> value were encoded on a single line, and with
> all trailing white-space removed>
>
>
> [Sig-Signer just identifies the key; if the URI is a URL, and that URL
> resolves to a well formatted SPKI template containing a public key, that
> key should be the one that was used to sign this template. alternately,
> there could be transfomration rules used to automatically generate a URL
> from the URI for both CRL and Key]
>
> Additional attribute for templates carrying public keys:
> Either
> Public-Key: <type> ";" <base64 encoding of pkcs-1 encoding of key>
> OR
> RSA-PublicKey-Modulus: <base64 encoding of modulus>
> RSA-PublicKey-Exponent: <base64 encoding of exponent>
>
> OR
> RSA-PublicKey-Modulus: text encoding of decimal val of modulus
> RSA-PublicKey-Exponent: text encoding of decimal value of exponent
>
Have I missed something? None of these proposed formats seem to have any
provision for key verification. Surely this is a vital (if possibly optional)
ingredient?
Presumably what is needed is some extra fields:
Sig-Verifying-Algorithm: <alg>
Sig-Verifying-Signer: <URI>
Sig-Verifying-Signature: <key>
Of course, these have no value to the recipient unless at some point up the
chain (if such a chain exists) they hit a URI they "trust". I would suggest
that one should allow multiple instances of these fields (they would sign all
the data except themselves and other verifying signatures). I expect there
should also be fields for the "type" of verifying signature, but I don't quite
have the strength to define them now ;-)
But here's a thought ... perhaps the verifier could state which fields (in the
main certificate) they have verified. Their signature would then sign for the
cert+their field list.
Cheers,
Ben.
>
> ---
> They say in online country So which side are you on boys
> There is no middle way Which side are you on
> You'll either be a Usenet man Which side are you on boys
> Or a thug for the CDA Which side are you on?
> National Union of Computer Operatives; Hackers, local 37 APL-CPIO
>
--
Ben Laurie Phone: +44 (181) 994 6435
Freelance Consultant and Fax: +44 (181) 994 6472
Technical Director Email: ben@algroup.co.uk
A.L. Digital Ltd, URL: http://www.algroup.co.uk
London, England.
Follow-Ups:
References: