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

Actually, thinking about it, the signature should be for those fields they've
verified (+the field list if that's deemed appropriate). This would allow new
CA-supported fields to be added without having to revalidate with other CAs.

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.

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