[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SPKI getting something done would be nice....
Why is it undesirable to use a "MIME/PGP-signed bodypart"
as an SPKI cert? (which is what I suggested)?
Such a SPKI cert would be directly usable then in
SKIP-supported
IPSEC, in secure email, and in signed-jar archives for
applets. The
opportunities for convergence based on the existing PGP
declarations
in all such standards are significant to ensure SPKI gets
easily co-located in these operational protocols which
require
a security infrastructure for authorization controls.
William Allen Simpson wrote:
> > From: Peter Williams <peter@verisign.com>
> > Subject: Re: multiple certification rules
> > Id like to see SPKI adopt a WG position that perhaps,
> whilst
> >
> > agreeing a default format for migration, profiles of
> other
> > deployed formats
> > could be represented as equivalent; why cannot a
> > PGP/MIME-signed
> > attachement play the format role of a SPKI certificate?
> > Surely,
> > the SPKI definitions on content can be expressed by
> defining
> >
> > a suitable mime type, rather than standardising "yet
> > another signing package" or abstract syntax
> > scheme. And there is no objective reason to restrict
> things
> > to PGP/MIME either.
> >
> In my view, going off in such a direction would be
> undesirable.
>
> This WG is supposed to be about establishing a "Simple"
> Public Key
> "Infrastructure".
>
> Earlier messages about incorporating X.509, and now Signed
> MIME messages
> of 80 lines of text encodings, do not meet the "simple"
> criteria held
> dearly in my mind. Nor is this an "infrastructure".
>
> > Content-Type: application/x-pkcs7-signature;
> name="smime.p7s"
> > Content-Transfer-Encoding: base64
> > Content-Disposition: attachment; filename="smime.p7s"
> > Content-Description: S/MIME Cryptographic Signature
>
> What I am waiting (and waiting and waiting) for is a nice
> simple
> certificate format, with reasonably restrictive sematics,
> and easy to
> interpret binary encodings.
>
> I've seen all the postings about how an interpretive
> escaping mechanism
> can be used for mode switches, to represent '{', and other
> problems, and
> I don't buy it. Not "Simple"!
>
> We reduced ("simplified") the ever burgeoning semantics at
> the Memphis
> meeting, and asked for a report on the complexity factor
> of programming
> for textual representation versus binary. The report
> wasn't issued, but
> it seems clear from various comments that binary won.
>
> I personally asked that new drafts come out more
> regularly, with change
> bars, and changes in only one major section at a time. In
> my copious
> experience, that allows more focused discussion. Instead,
> no drafts
> have appeared, and the discussion is ranging all over the
> map, from
> "trust" to "format" to "migration" from all previous
> mechanisms.
>
> So, let's get the lead out. Where is our next draft of
> SPKI?
>
> (I'm trying to be nice; the first draft of this message
> said
> "worse-than-useless" early on and was rather more
> scathing.)
>
> WSimpson@UMich.edu
> Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9
> 9B 6A 15 2C 32
> BSimpson@MorningStar.com
> Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F
> 5E 1D C2 C1 A2
Follow-Ups: