[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IETF-63 Proceedings Submission
Of course this didn't make it into the minutes; this messages
happened well after the IETF met in August. The minutes are a
status report of the IETF meeting; It does not take into account
messages that have been processed *since* the IETF.
And no, we're not in final call, yet. I need to catch up and
make sure we've handled all the open issues. I'll see if I
can get to that this week.
Ian G <iang@xxxxxxxxxxxxx> writes:
> Derek Atkins wrote:
>> - If you want changes in wording - need to be compatable and suggest text.
>> - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15
> I guess the below didn't make it then. Oh well.
> -------- Original Message --------
> Subject: Re: Signature types
> Date: Sat, 27 Aug 2005 10:25:07 +0100
> From: Ian G <iang@xxxxxxxxxxxxx>
> Organization: http://financialcryptography.com/
> To: ietf-openpgp@xxxxxxx
> References: <20050827075018.GA17967@xxxxxxxxxxxxxxxx>
> Daniel A. Nagy wrote:
>> ... [some stuff]
> On that section, but not on Daniel's question, it occurs to
> me that the caveat found half way down ("Please note that
> the vagueness...") could be usefully expanded to cover all
> of 5.2.1.
> Something like:
> 5.2.1. Signature Types
> There are a number of possible meanings for a signature.
> By convention, OpenPGP suggests meanings by the following
> signature type octets in any given signature.
> Please note that the vagueness of these signature claims
> is not a flaw, but a feature of the system. Cryptographic
> signing technology alone cannot make these claims true,
> and a relying party would need to examine the intentions
> of any signer, and the wider context of the system and
> environment in order to assess any claims. OpenPGP places
> final authority and responsibility on the receiver of any
> Which then allows a simplification of the post-0x13 comment:
> Please note that one authority's casual certification
> might be more rigorous than some other authority's
> positive certification. These classifications allow a
> certification authority to issue fine-grained claims.
> Most OpenPGP implementations make their "key signatures" as 0x10
> certifications. Some implementations can issue 0x11-0x13
> certifications, but few differentiate between the types.
> As an alternate, such general commentary could append to the
> end of the section - but in legal terms, if it is a warning
> as to limitations, it should be at the front. Given the
> somewhat poisoned waters of digital signatures, I'd prefer
> to see the disclaims before any claims.
> PS: are we in final call already?
Derek Atkins 617-623-3745
Computer and Internet Security Consultant