[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)

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.



> ---
> 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: