Subject: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)

From: [email-masked]
Date: Fri, 19 May 2000 12:04:06 +0900

here are some more clarification questions...

-section 4.3 is titled "Packet Tags", and the term "packet tag" is used
 throughout, but strictly speaking, shouldn't that be "content tag" as
 per section 4.2?

-section 5.2.3 describes the version 4 signature packet format.  one of the
 fields is described as:

   Hashed subpacket data. (zero or more subpackets)

 what is meant by "hashed" here?  are the contents of this field actual
 subpackets or hash(subpackets)?  i presume it is the former and that 
 "hashed" refers to the fact that the "hashed subpackets" field is included
 among the material that is hashed when a signature is computed.  

 so "normally" the contents of the "hashed subpackets" field and the 
 "unhashed subpackets" field should be identical, correct?

 if this is correct, i think it would be helpful to explicitly state that
 the contents of the "hashed supackets" field and the "unhashed subpackets"
 field are usually (should be?) the same.  alternatively, perhaps the
 fields could be given different names?  (actually, i think all fields 
 should be named "bruce" to avoid confusion ;-P )

 out of curiosity, why are the field contents repeated?
 
-section 5.2.3.1 describes the signature subpacket specification.  in
 the description of the subpacket header there is the following:

   - the subpacket type (1 octet)

 then, shortly after:

   The value of the subpacket type octet may be:

       2 = signature creation time
       ...
       100 to 110 = internal or user-defined

 however:

   Bit 7 of the subpacket type is the "critical" bit.  If set, it
   denotes that the subpacket is one that is critical for the evaluator
   of the signature to recognize.  If a subpacket is encountered that
   is marked critical but is unknown to the evaluating software, the
   evaluator SHOULD consider the signature to be in error.

 i presume this means that the legal values (2, 3, 4, 5, 6, 7, etc.) listed
 for the subpacket type octet actually refer to bits 6 through 0 of the
 octet, and not that there haven't been any "critical subpacket types" defined
 yet.  is this correct?  if so, i think alternate wording would be less
 ambiguous.

-section 5.2.3.3 has some notes on self-signatures.  the following text
 appears therein:

   If the key is located by key id, then algorithm of the default user id 
   of the key provides the default symmetric algorithm.

 the term "default user id" is used -- i failed to locate a definition for
 this term.  could someone point out the definition in the specification 
 or give one?

thanks.

---

From: "L. Sassaman" <[email-masked]>
Date: Thu, 18 May 2000 20:58:58 -0700 (PDT)

>  this term.  could someone point out the definition in the specification 

I believe that "default user id" is synonymous with "primary user id".

- From the current draft:

5.2.3.19. Primary user id

   (1 octet, boolean)

   This is a flag in a user id's self signature that states whether
   this user id is the main user id for this key. It is reasonable for
   an implementation to resolve ambiguities in preferences, etc. by
   referring to the primary user id. If this flag is absent, its value
   is zero. If more than one user id in a key is marked as primary, the
   implementation may resolve the ambiguity in any way it sees fit.

- --Len.

__

L. Sassaman

System Administrator                |  "Everything must end; 
Technology Consultant               |   meanwhile we must 
icq.. 10735603                      |   amuse ourselves." 
pgp.. finger://ns.quickie.net/rabbi |             --Voltaire

---

From: [email-masked]
Date: Fri, 19 May 2000 13:59:36 +0900

From: "L. Sassaman" <[email-masked]>
Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3)
Date: Thu, 18 May 2000 20:58:58 -0700 (PDT)
Message-ID: <[email-masked]>

>    implementation may resolve the ambiguity in any way it sees fit.

hmm...i don't get the impression that they are quite synonymous.

section 5.2.3.2 uses the definite article (as in "the default user id"):

  If the key is located by key id, then [the] algorithm of the default user 
  id of the key provides the default symmetric algorithm.

i presume there is only one "default user id" -- that is, given a
correct openpgp implementation, for any key (not packet, but entire
key), the implementation should have some algorithm to decide what
counts as the default user id.

section 5.2.3.19 states that more than one user id in a key can be
marked as primary and that the implementation may resolve the
ambiguity in any way it sees fit.  i presume this means that the
implementation must choose a default user id, but it has the freedom
to decide how this choosing is done.  is that correct?

---

From: "L. Sassaman" <[email-masked]>
Date: Thu, 18 May 2000 22:53:29 -0700 (PDT)

> to decide how this choosing is done.  is that correct?

Right. There is only one primary user id (or default user id) per
key. More than one user id can have a self-sig with the primary user id
bit set, but the implementation must in some way determine which is the
"real" primary user id. I believe that checking the signature date, and
picking the most recent, makes a lot of sense... but as the RFC says, it
is up to the implementation.

- --Len.

__

L. Sassaman