headers
David Shaw | 11 May 2005 05:43

Critical bits and notations


Here's an odd corner case, one that I'd be grateful for some thoughts
on: what does the critical bit mean in the context of a signature
notation?  Does the critical bit refer to support of the notation
subpacket in general, or to the specific notation given in the
critical notation subpacket?

For example, take an implementation that can read notations, and
specifically understands and acts on the "foo" notation.  Given that,
it's very clear that this implementation should accept a critical
notation "foo=1".  Now try a critical notation of "bar=2".  Should the
implementation accept it because it knows what a notation is, and
implements notations, or should it reject it because it doesn't know
what the specific "bar" notation is?

The draft has this to say on the subject of critical bits for
signature subpackets:

   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.

   An evaluator may "recognize" a subpacket, but not implement it. The
   purpose of the critical bit is to allow the signer to tell an
   evaluator that it would prefer a new, unknown feature to generate
   an error than be ignored.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hal Finney | 11 May 2005 06:28

Re: Critical bits and notations


In my opinion, the critical bit on a notation packet should mean
that the implementation needs to recognize that particular notation,
not just notation packets in general.  Otherwise we would have no way
of expressing the requirement that the particular notation packet be
understood.

I also wouldn't say that human-readable means that it is enough to display
it.  My interpretation of human-readable is that it is OK to display it
to a person, i.e. that the data is in UTF-8, but not that displaying it
to a person is sufficient to claim full support of the packet.

Hal Finney
Permalink | Reply | 574 comments |
headers
Werner Koch | 11 May 2005 09:17
Picon
Favicon

Re: Critical bits and notations


On Tue, 10 May 2005 21:28:36 -0700 (PDT), "Hal Finney" said:

> In my opinion, the critical bit on a notation packet should mean
> that the implementation needs to recognize that particular notation,
> not just notation packets in general.  Otherwise we would have no way

I agree.  This matches the way the critical flag of CMS' extended
attributes is used.

Shalom-Salam,

   Werner
Permalink | Reply | 0 comments |
headers
Rachel Willmer | 11 May 2005 16:22

minor comments on draft-ietf-openpgp-rfc2440bis-12.txt


Minor nitpicks:

1/ 5.2.3.23 "Reason for revocation"

"superceded" should be "superseded"

2/ Sections 5.2.3.8 and 5.2.3.9 both reference algorithm lists in
section 6, which is currently the section entitled "Radix-64
conversions". I suspect the reference should be to Section 9.

Rachel
Permalink | Reply | 1 comment |
headers
David Shaw | 11 May 2005 16:35

Re: Critical bits and notations


On Tue, May 10, 2005 at 09:28:36PM -0700, "Hal Finney" wrote:
> 
> In my opinion, the critical bit on a notation packet should mean
> that the implementation needs to recognize that particular notation,
> not just notation packets in general.  Otherwise we would have no way
> of expressing the requirement that the particular notation packet be
> understood.

That makes good sense, and I agree.  However, the text in the draft
doesn't exactly say this (and rather implies the opposite).

I suggest adding this sentence (or similar) to the end of section
5.2.3.16. Notation Data:

  When used on a notation subpacket, the critical bit refers to that
  particular notation, and not to notation subpackets in general.

David
Permalink | Reply | 573 comments |
headers
David Shaw | 11 May 2005 23:25

Re: Tag 11 unclear


On Tue, Apr 26, 2005 at 12:02:23PM -0700, "Hal Finney" wrote:
> We might also want to note here that literal packet headers are not
> signed, unless the literal packet is first wrapped in another packet
> such as a compressed packet.  Only the body of a literal packet is
> signed in a message which consists of sig-packet, literal-packet.
> (Or sig1-packet, literal-packet, sig-packet)

What about (onepass, literal, literal, literal, sig) ?  Treat as the
multiple literal bodies concatenated together?

David
Permalink | Reply | 0 comments |
headers
Hal Finney | 11 May 2005 23:51

Re: Tag 11 unclear


David Shaw writes:
> What about (onepass, literal, literal, literal, sig) ?  Treat as the
> multiple literal bodies concatenated together?

I don't think we should allow this.  There are too many potentials
for mischief due to the absence of boundary information feeding into
the signature.

Hal
Permalink | Reply | 1 comment |
headers
David Shaw | 12 May 2005 00:09

Re: Tag 11 unclear


On Wed, May 11, 2005 at 02:51:33PM -0700, "Hal Finney" wrote:
> 
> David Shaw writes:
> > What about (onepass, literal, literal, literal, sig) ?  Treat as the
> > multiple literal bodies concatenated together?
> 
> I don't think we should allow this.  There are too many potentials
> for mischief due to the absence of boundary information feeding into
> the signature.

Note that this is currently legal syntax in the grammar.

(I actually suggested the run-of-literal-packets grammar change to
resolve a problem elsewhere in the document, but that doesn't mean I
was right).

David
Permalink | Reply | 0 comments |
headers
Jon Callas | 12 May 2005 01:42
Gravatar

Re: minor comments on draft-ietf-openpgp-rfc2440bis-12.txt


On 11 May 2005, at 7:22 AM, Rachel Willmer wrote:

>
> Minor nitpicks:
>
> 1/ 5.2.3.23 "Reason for revocation"
>
> "superceded" should be "superseded"

Done. Both occurrences.

>
> 2/ Sections 5.2.3.8 and 5.2.3.9 both reference algorithm lists in
> section 6, which is currently the section entitled "Radix-64
> conversions". I suspect the reference should be to Section 9.
>

Done.

	Jon
Permalink | Reply | 0 comments |
headers
Jon Callas | 12 May 2005 01:54
Gravatar

Re: Critical bits and notations


On 11 May 2005, at 7:35 AM, David Shaw wrote:

>
> On Tue, May 10, 2005 at 09:28:36PM -0700, "Hal Finney" wrote:
>>
>> In my opinion, the critical bit on a notation packet should mean
>> that the implementation needs to recognize that particular notation,
>> not just notation packets in general.  Otherwise we would have no way
>> of expressing the requirement that the particular notation packet be
>> understood.
>
> That makes good sense, and I agree.  However, the text in the draft
> doesn't exactly say this (and rather implies the opposite).
>

I agree with Hal. I don't think that the text in the draft implies the 
opposite, however. Here's a quote:

    ... The
    purpose of the critical bit is to allow the signer to tell an
    evaluator that it would prefer a new, unknown feature to generate an
    error than be ignored.

This says to me that if you see a notation you don't understand, you 
should error out.

Notations are our extension mechanism. It strikes me as perverse to 
think that you only have to know the general concept of extensions and 
not the specific extension.
(Continue reading)

Permalink | Reply | 4 comments |

Gmane