Subject: Re: Multiple signatures in clearsigned messages (was Re: Cleartext Signatures)

From: [email-masked] ("Hal Finney")
Date: Wed, 12 Oct 2005 00:07:13 -0700 (PDT)

Daniel Nagy writes about multiple cleartext signatures:
> Some details are missing. For instance, is the order salient? One-pass
> signantures have to be bracketed, and clearsigned documents are supposed be
> verifiable in one pass as well. But it does not necessarily imply that the
> hash algorithms should be listed in reverse signature order in the
> beginning. Actually, the standard says very little on how to go about it.

I don't think there is much benefit to putting the hashes in the (reverse)
order of the signatures.  Rather, you list all of the hashes that will
be used by any of the signatures, then simultaneously accumulate all
hash values as you scan the message in one pass.  Now you can verify
each signature and you would have the hash value at hand.

> It
> would definitely help one-pass verification, if signatures that refer to
> other signatures (e.g. notarization sigs) were mandated to either follow or
> precede the signatures they are refering to. Both solutions have their
> benefits, but deciding one way or another would be better than allowing
> arbitrary order. It would be nice to have a paragraph or two elaborating on
> these issues.

I am a bit uncomfortable with the notarization signature in general.
We have it in the draft but have no experience with it in reality,
which is kind of the opposite of the usual IETF procedure.  I guess it
was somebody's bright idea that got stuck in, in case people might want
to use it someday.

The fact that we may have to add further rules clarifying how to use it
just emphasizes our lack of experience with the construct.  Often with
these things you don't find the problems until you actually try to use it
for something and interoperate with others.  Given that notary signatures
have been in the draft in some form or other for years without seeing
any use that I know of, should we consider taking them out?

Hal Finney

---

From: Ian G <[email-masked]>
Date: Wed, 12 Oct 2005 12:03:11 +0100

> any use that I know of, should we consider taking them out?

I think as long as the semantics - the legal
or otherwise meaning - of the digsig are left
explicitly vague and up to the signing and
relying parties, then the existance of a notary
signature form just represents a spot where
two cooperating parties could agree to do a
notary-like signature.  It's up to them all to
sort out the details...

Looking at the section 5.2.1. Signature Types
There is this odd para half way through the
list:

         Please note that the vagueness of these certification claims is
         not a flaw, but a feature of the system. Because OpenPGP places
         final authority for validity upon the receiver of a
         certification, it may be 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.

I suggest that this is out of place and may be
better served being moved to the front or back
of the section, so that it serves as a general
caveat of vagueness and user-authority on the
issue of signature semantics.

I would prefer the disclaimer to vaguery to be
at the beginning because that's how lawyers like
it.  So, Something like this:

   5.2.1. Signature Types

     There are a number of possible meanings for a signature, which
     may be indicated in a signature type octet in any given signature.
     Please note that the vagueness of these meanings is
     not a flaw, but a feature of the system. Because OpenPGP places
     final authority for validity upon the receiver of a
     signature, it may be that one signer's casual
     act might be more rigorous than some other authority's
     positive act.

     These meanings are:

     0x01:...

iang

PS: The concept of technology doing signatures is
quite scary, and notary signatures are a step
further into that area;  this group has no real
tools to deal with it as we have no lawyers
here, and even if we did, we'd need to cover
different codes (common, civil, islamic...)
and different digsig laws.  Before this ever
gets to be a tech question, it's a major academic
challenge.  The people who looked at basic digsigs
in the mid 90s bungled it comprehensively, so it's
not as if we can even say "well, just pay someone..."

It's the sort of thing that might fit much more
nicely in another document.  "Notary Signatures
Extension to OpenPGP."  But as you say, I'd prefer
to see someone *do it* in code and in practice to
flush out the lessons.

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 12 Oct 2005 15:06:40 +0200

> each signature and you would have the hash value at hand.

Actually, the hash value is not enough; you need to carry the whole message
digest object with its internal state. In a system/library where it is not
cloneable, this might be a problem. But I agree that it's no big deal. What
you write above is perfectly consistent with the standard and my planned
implementation. I am not aware of any actual implementation of multiple
cleartext signatures.
 
> any use that I know of, should we consider taking them out?

Please don't. I do have a very good use for them and I'm going to go ahead
with an implementation. As soon as it's working reliably and securely, I
will write up the specifications for inclusion in the standard.

-- 
Daniel

---

From: "Brian G. Peterson" <[email-masked]>
Date: Wed, 12 Oct 2005 09:50:32 -0500

> will write up the specifications for inclusion in the standard.

I second this.  A workable notary signature method for both clear-signed and 
pgp/mime is badly needed for evidentiary reasons.  

The hypothetical human rights example discussed a few weeks ago applies 
clearly here, where a file/message may pass through multiple hands before 
arriving at it's final destination, and the original signer may be dead by 
the time it gets to the final destination.  Having a notary chain of 
signatures over the same original can provide valuable chain of evidence 
information.

Regards,

  - Brian Peterson

---

From: David Shaw <[email-masked]>
Date: Wed, 12 Oct 2005 11:10:16 -0400

> any use that I know of, should we consider taking them out?

While I hate to say it, given the number of hours that went into it
thus far, I think I agree.  Last call is approaching, and we have no
implementations of it and no experience with it.

This isn't to say that I think we should scrap notary signatures -
just that it might be a good idea to bump them into their own RFC so
as not to delay 2440bis.  I don't believe that implementation and
experience can be achieved in time, and I'd rather see them done right
than done in 2440bis.

David

---

From: David Shaw <[email-masked]>
Date: Wed, 12 Oct 2005 11:13:08 -0400

> pgp/mime is badly needed for evidentiary reasons.  

I definitely agree they are useful, but given that 2440bis last call
ends in 16 days and we have no implementations (much less two
interoperable ones), let's move this to a new RFC.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 12 Oct 2005 17:31:30 +0200

> interoperable ones), let's move this to a new RFC.

Sure, the true specs will be in the new RFC, but please don't remove from
RFC2440bis what is already there.

-- 
Daniel

---

From: [email-masked] (Daniel A. Nagy)
Date: Wed, 12 Oct 2005 17:35:39 +0200

> experience can be achieved in time, and I'd rather see them done right

What is already there is vague and general enough not to interfere with
future implementations and at least gives some guidelines to implementers,
who may come up with interoperable solutions on their own. Please do not
remove the notary signature types from this RFC.

The actual, detailed specification with examples backed up by an open-source
implementation will go into a new RFC; I have no problem with that.

-- 
Daniel

---

From: Derek Atkins <[email-masked]>
Date: Wed, 12 Oct 2005 11:44:02 -0400

<chair hat on>

As a process point..  2440bis is going into PROPOSED standard, which
means we don't need the deployment experience right now.  There's
no need to rip out this section now -- we can always remove it
before going to DRAFT standard if we don't get the experience
by then.

So, if there is concensus to remove it now we can..  But from
a process standpoint there's no need to remove it if we think
the language is clear about how to create and parse and understand
the packet type.

</chair hat off>

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Wed, 12 Oct 2005 11:47:09 -0400

> interoperable ones), let's move this to a new RFC.

We don't need this now.  That's needed to go to DRAFT standard.
2440bis is going to PROPOSED (because there's been significant
churn).

To go from PROPOSED to DRAFT we need the implementation experience,
and the draft can only clarify or remove, not add or change.  I.e.,
you cannot change a packet format, but you can clarify ambiguities or
remove packets that haven't been implemented.  But this wont happen
until next year.

-derek