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