[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, I meant <signature> not <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.
And here I mean CA in the widest possible sense.
Cheers,
Ben.
>
> 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.
--
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.
References: