Subject: Four Points.

From: Ian Grigg <[email-masked]>
Date: Wed, 27 Oct 2004 12:30:37 +0100

Four points, indicated by roman numerals.

The first suggests a change of substance.

iang

====================================================================
      5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18)
      ...

i. Can we migrate Tag 18 to a MUST support, or at least a MUST read?
Something like:

    A conforming implementation MUST support decryption of this
    packet.

( At the moment, it is a "SHOULD prefer" which I take to mean an
implementation should strive to send out/encrypt these packets when
it has a choice.  That's fine, as long as there is some statement
on reading/decrypting.)

When was this feature introduced?  I suspect enough time has
passed, and enough implementations are doing it that we can
move this to a MUST.  It is certainly the standard that these
days, protocols should be MAC'd or MDC's in some fashion.

ii. It seems that section 5.13 duplicates much of the special
CFB processing rules, except for a caveat at the end.  Maybe
duplication is needed here for care reasons, or maybe this could
more readily refer to "12.7. OpenPGP CFB mode"  Just a thought.

    ...
    During decryption, the plaintext data should be hashed with SHA-1,
    including the prefix data as well as the packet tag and length field
    of the Modification Detection Code packet.  The body of the MDC
    packet, upon decryption, is compared with the result of the SHA-1
    hash.  Any difference in hash values is an indication that the
    message has been modified and SHOULD be reported to the user.
    Likewise, the absence of an MDC packet, or an MDC packet in any
    position other than the end of the plaintext, also represent message
    modifications and SHOULD also be reported.

iii. The latter 2 sentences above seem less severe than the
similar sentence in the below section 13, section starting
"In late summer 2002..." (below, at end).

      * In late summer 2002...
        ...
        An implementation
        MUST treat an MDC failure as a security problem, not merely a
        data problem.

I'd suggest adding
reference to the MUST treat as a security problem, above.
Perhaps:

    ...  Any difference in hash values is an indication that the
    message has been modified and MUST be treated as a security
    problem.  Likewise, the absence of an MDC packet, or an MDC
    packet in any position other than the end of the plaintext,
    also represent message modifications and MUST be treated as
    a security problem.  These events SHOULD be reported to the
    user.

Although I think it could be tidied up more:

    Any failure of the MDC indicates that the message has been
    modified and MUST be treated as a security problem.
    Failures include a difference in the hash values, but also
    the absence of an MDC packet, or an MDC packet in any
    position other than the end of the plaintext.  Any failure
    SHOULD be reported to the user.

      13. Security Considerations

      * This specification uses Public Key Cryptography technologies.
        Possession of the private key portion of a public-private key
        pair is assumed to be controlled by the proper party or parties.

iv. This seems unworthy of stating, but either way, might be better written:

      * This specification uses Public Key Cryptography technologies.
        It is assumed that the private key portion of a public-private key
        pair is controlled and secured by the proper party or parties.

====================================================================

---

From: Werner Koch <[email-masked]>
Date: Wed, 27 Oct 2004 14:27:51 +0200

> days, protocols should be MAC'd or MDC's in some fashion.

About summer 2000 after a predecessor version in spring 1999.

>     a security problem.  These events SHOULD be reported to the

It is a possible security problem.  There is far too many encrypted
data without the MDC packet in use.  A strong warning is okay, but a
severe error won't be good.

If we would flag that as an error, the implementation should not even
output the decrypted messages which clearly is not acceptable to most
users trying to restore their backup or reading an archived mail.  An
implementation may still decide what to do but the standard should not
enforce it.

  Werner

---

From: Ian Grigg <[email-masked]>
Date: Wed, 27 Oct 2004 13:59:49 +0100

> implementation may still decide what to do but the standard should not

Backups .. a good point.  Hold on though.

If I have created a backup in pre-MDC times, I will
have used the previous packet layout, Tag 9.  So
I can read it as is, as a Tag 9.

Nothing I am suggesting should be taken to say
that Tag 9 should be phased out or made deprecated.
Rather, what I am suggesting is that implementations
MUST be able to read Tag 18s and when they come across
them, they MUST follow the security rules.

(Even if were to make sending/encrypting a MUST, I
don't think we are at the point of saying that an
implementation MUST NOT send out Tag 9s.)

OTOH, are you suggesting that some implementations
created Tag 18s without correct MDCs?  That seems to
be an error, and those should be treated as failures,
as described, no?

Does that make it clearer?

iang

PS: 5.7. Symmetrically Encrypted Data Packet (Tag 9)

---

From: Werner Koch <[email-masked]>
Date: Wed, 27 Oct 2004 15:34:32 +0200

> that Tag 9 should be phased out or made deprecated.

I see.  Forget about my comments, they are not valid then. 

> created Tag 18s without correct MDCs?  That seems to

Not that I know of.

  Werner

---

From: Jon Callas <[email-masked]>
Date: Wed, 27 Oct 2004 15:19:19 -0700

Good points. I'll incorporate them when I have a moment. I did some 
work on the draft yesterday and would have sent out a new one but the 
pre-meeting close on new drafts was Monday.

My only comment myself is that I think there's a lot of implementation 
notes in the draft as it is, and if anything too many. There is also a 
lot of paternal tongue-clucking about what people should do when 
there's an error. I'll tidy up, but I think there is if anything too 
much as it is.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 29 Oct 2004 16:08:50 -0700

>    A conforming implementation MUST support decryption of this

I'm putting this in, but I note that makes the minimal implementation 
larger. Since not one person has squealed, I'm hearing rough consensus 
in that silence.

> more readily refer to "12.7. OpenPGP CFB mode"  Just a thought.

I put a note in. However, there's a small difference between the MDC 
and the other version. The MDC version doesn't resync the CFB chain.

>    SHOULD be reported to the user.

I took this language and broke it out into its own paragraph.

>        pair is controlled and secured by the proper party or parties.

I think this particular warning dates all the way back to 1991, but I'm 
not sure. I'd go for taking it out, myself, because I agree it to be a 
"Well, Duh!" comment. However, I also remember it being Extremely 
Important to someone back in the Crypto Wars.

I'm taking your rewrite.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Four Points.
Date: Fri, 29 Oct 2004 16:08:50 -0700
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

>    A conforming implementation MUST support decryption of this

I'm putting this in, but I note that makes the minimal implementation 
larger. Since not one person has squealed, I'm hearing rough consensus 
in that silence.

> more readily refer to "12.7. OpenPGP CFB mode"  Just a thought.

I put a note in. However, there's a small difference between the MDC 
and the other version. The MDC version doesn't resync the CFB chain.

>    SHOULD be reported to the user.

I took this language and broke it out into its own paragraph.

>        pair is controlled and secured by the proper party or parties.

I think this particular warning dates all the way back to 1991, but I'm 
not sure. I'd go for taking it out, myself, because I agree it to be a 
"Well, Duh!" comment. However, I also remember it being Extremely 
Important to someone back in the Crypto Wars.

I'm taking your rewrite.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Four Points.
Date: Wed, 27 Oct 2004 15:19:19 -0700
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

	Jon

> The first suggests a change of substance.

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Four Points.
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 27 Oct 2004 15:34:32 +0200
Sender: [email-masked]

Not that I know of.

  Werner

Date: Wed, 27 Oct 2004 13:59:49 +0100
From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
CC: [email-masked]
Subject: Re: Four Points.
Sender: [email-masked]

iang

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Four Points.
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 27 Oct 2004 14:27:51 +0200
Sender: [email-masked]

  Werner

Date: Wed, 27 Oct 2004 12:30:37 +0100
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Four Points.
Sender: [email-masked]

iang

    ...

      * In late summer 2002...
        ...
        An implementation

I'd suggest adding

From: Jon Callas <[email-masked]>
Subject: Re: Key size suggestions
Date: Tue, 26 Oct 2004 15:06:39 -0700
To: David Shaw <[email-masked]>, OpenPGP <[email-masked]>
Sender: [email-masked]

On 26 Oct 2004, at 2:54 PM, David Shaw wrote:

>
> This is more of a question to the WG.  I'll make a formal change
> suggestion if the folks here think it is warranted.
>
> 2440 came out in 1998, and included some general recommendations as to
> minimum key size: 768 bits for all of DSA, RSA, and Elgamal.  Today, 6
> years later, I doubt these values would be used, even as minimums.
>
> My intent is not to get into a discussion as to algorithm strength,
> and the best key length to use, etc, but to ask if *any* static
> recommendations as to key length are useful.  I expect the new RFC
> will be around for a good long time, and over that lifespan, the state
> of the art in attacks will undoubtedly improve.
>
> The draft already contains a note in the security considerations
> section reminding people to check the current literature for recent
> algorithm news.  Perhaps that is sufficient.
>

I beat you to it. I upped them to 1024 bits and put in a statement for 
Elgamal, as well.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] Elgamal Signature remnants
Date: Tue, 26 Oct 2004 15:05:10 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 26 Oct 2004, at 2:31 PM, David Shaw wrote:

>
> Section 14 references Elgamal sign+encrypt keys, and section 17 has a
> citation for the Bleichenbacher paper about Elgamal signatures.
>
> Since we have dropped Elgamal signatures from the standard, these can
> probably both go.
>

Thanks for the pointer. I was going through looking at deprecation and 
found one or two of those. I'll look again.

	Jon

Date: Tue, 26 Oct 2004 17:54:33 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Key size suggestions
Mail-Followup-To: [email-masked]
Sender: [email-masked]

This is more of a question to the WG.  I'll make a formal change
suggestion if the folks here think it is warranted.

2440 came out in 1998, and included some general recommendations as to
minimum key size: 768 bits for all of DSA, RSA, and Elgamal.  Today, 6
years later, I doubt these values would be used, even as minimums.

My intent is not to get into a discussion as to algorithm strength,
and the best key length to use, etc, but to ask if *any* static
recommendations as to key length are useful.  I expect the new RFC
will be around for a good long time, and over that lifespan, the state
of the art in attacks will undoubtedly improve.

The draft already contains a note in the security considerations
section reminding people to check the current literature for recent
algorithm news.  Perhaps that is sufficient.

David

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] UTF-8 CRLF
Date: Tue, 26 Oct 2004 14:39:29 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 26 Oct 2004, at 2:19 PM, David Shaw wrote:

>
> My mistake.  I had missed that change.  I withdraw the suggestion.
>

And I backed out the change.

	Jon

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] End-of-line whitespace in 0x01 sigs
Date: Tue, 26 Oct 2004 14:35:43 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

I made this change, and I'll also make a comment that's my opinion:

If you have an implementation that's trimming, you don't have to change.

If you think that trimming is a good idea, go right ahead.

There is nothing in OpenPGP that says that an implementation can't make 
reasonable transformations on text. This includes trimming, but also 
things like reformatting paragraphs with line ends into paragraphs 
without. Your user base might howl, but that's between you and them.

I hope this finally puts this to rest. I apologize to the working group 
for the whole mess.

	Jon

On 26 Oct 2004, at 2:10 PM, David Shaw wrote:

>
> In section 5.2.1, the text currently reads:
>
>    0x01: Signature of a canonical text document.
>        This means the signer owns it, created it, or certifies that it
>        has not been modified.  The signature is calculated over the
>        text data with its line endings converted to <CR><LF> and
>        trailing spaces (0x020) and tabs (0x09) removed.
>
> I suggest:
>
>    0x01: Signature of a canonical text document.
>        This means the signer owns it, created it, or certifies that it
>        has not been modified.  The signature is calculated over the
>        text data with its line endings converted to <CR><LF>.
>
> This is the same as before but trailing whitespace is not removed.
> Note that I'm only talking about 0x01 signatures here.  Cleartext
> signatures, and the trimming therein, are unchanged by this.
>
> Rationale: As much as possible, I feel that the data that you get out
> during decryption should be the same as the data that you put in to be
> encrypted, and the current behavior violates this.
>
> There are good reasons to do whitespace trimming for cleartext
> signatures (mail mangling, cut and paste mangling, etc).  These
> reasons do not apply to an 0x01 signature as it is *not* cleartext -
> rather, it is protected inside the binary or ascii armor shell.  In
> general, if we have no good reason to tamper with user supplied input,
> I think we should keep hands off.
>
> Speaking about PGP and GnuPG, there is no real impact to this change.
> The only messages that are affected are detached 0x01 signatures, and
> since those don't interoperate now (never did), we can hardly make it
> worse...
>
> David
>

Date: Tue, 26 Oct 2004 17:31:29 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] Elgamal Signature remnants
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Section 14 references Elgamal sign+encrypt keys, and section 17 has a
citation for the Bleichenbacher paper about Elgamal signatures.

Since we have dropped Elgamal signatures from the standard, these can
probably both go.

David

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] Some capitalization oddities
Date: Tue, 26 Oct 2004 14:31:42 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 26 Oct 2004, at 1:52 PM, David Shaw wrote:

>
> In section 5.2.3.23, "User ID" is rendered as "user Id".
>
> In sections 11.2, and 14, "key ID" is rendered as "key id".
>
> Not an earth shattering problem, but consistency is nice (everywhere
> else both of these items are consistent).
>

Done.

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: [ISSUE] UTF-8 CRLF
Date: Tue, 26 Oct 2004 14:29:46 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

>
> Suggest to add:
>
>   For the 'u' UTF8 literal packet, the minimal UTF8 encoding for the
>   <CR><LF> line endings SHOULD be used.  That is, 0x0D 0x0A and not
>   0xC0 0x8D 0xC0 0x8A or other multibyte encodings.
>

Done.

	Jon

Date: Tue, 26 Oct 2004 17:26:39 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] Call V4 V4
Mail-Followup-To: [email-masked]
Sender: [email-masked]

Section 11.1 contains the sentence:

  In a key that has a main key and subkeys, the primary key MUST be a
  key capable of certification.

Suggest to change this to:

  In a V4 key, the primary key MUST be a key capable of certification.

Rationale:

Frankly, because a while back, I read this as saying that if you have
a V4 key without subkeys, then the key isn't necessarily required to
be able to certify (and could thus be encrypt-only).  Pretty much
everyone else read the same thing as saying that the primary key must
be capable of certification no matter what.  Saying "V4" here instead
of "key that has a main key and subkeys" cannot be misunderstood.

David

Date: Tue, 26 Oct 2004 17:19:50 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: [ISSUE] UTF-8 CRLF
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Oct 26, 2004 at 11:03:23PM +0200, Florian Weimer wrote:
> 
> * David Shaw:
> 
> > The last sentence of section 5.9 reads:
> >
> >   Text data is stored with <CR><LF> text endings (i.e. network-normal
> >   line endings).  These should be converted to native line endings by
> >   the receiving software.
> >
> > Suggest to add:
> >
> >   For the 'u' UTF8 literal packet, the minimal UTF8 encoding for the
> >   <CR><LF> line endings SHOULD be used.  That is, 0x0D 0x0A and not
> >   0xC0 0x8D 0xC0 0x8A or other multibyte encodings.
> 
> This isn't valid UTF-8.  A UTF-8 implementation MUST NOT decode these
> octets, but MUST flag an error.  The most recent UTF-8 RFC is quite
> explicit in this regard.

My mistake.  I had missed that change.  I withdraw the suggestion.

David

Date: Tue, 26 Oct 2004 17:10:28 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] End-of-line whitespace in 0x01 sigs
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In section 5.2.1, the text currently reads:
 
   0x01: Signature of a canonical text document.
       This means the signer owns it, created it, or certifies that it
       has not been modified.  The signature is calculated over the
       text data with its line endings converted to <CR><LF> and
       trailing spaces (0x020) and tabs (0x09) removed.
  
I suggest:
 
   0x01: Signature of a canonical text document.
       This means the signer owns it, created it, or certifies that it
       has not been modified.  The signature is calculated over the
       text data with its line endings converted to <CR><LF>.
 
This is the same as before but trailing whitespace is not removed.
Note that I'm only talking about 0x01 signatures here.  Cleartext
signatures, and the trimming therein, are unchanged by this.
 
Rationale: As much as possible, I feel that the data that you get out
during decryption should be the same as the data that you put in to be
encrypted, and the current behavior violates this.

There are good reasons to do whitespace trimming for cleartext
signatures (mail mangling, cut and paste mangling, etc).  These
reasons do not apply to an 0x01 signature as it is *not* cleartext -
rather, it is protected inside the binary or ascii armor shell.  In
general, if we have no good reason to tamper with user supplied input,
I think we should keep hands off.

Speaking about PGP and GnuPG, there is no real impact to this change.
The only messages that are affected are detached 0x01 signatures, and
since those don't interoperate now (never did), we can hardly make it
worse...

David

To: [email-masked]
Subject: Re: [ISSUE] UTF-8 CRLF
From: Florian Weimer <[email-masked]>
Date: Tue, 26 Oct 2004 23:03:23 +0200
Sender: [email-masked]

* David Shaw:

> The last sentence of section 5.9 reads:
>
>   Text data is stored with <CR><LF> text endings (i.e. network-normal
>   line endings).  These should be converted to native line endings by
>   the receiving software.
>
> Suggest to add:
>
>   For the 'u' UTF8 literal packet, the minimal UTF8 encoding for the
>   <CR><LF> line endings SHOULD be used.  That is, 0x0D 0x0A and not
>   0xC0 0x8D 0xC0 0x8A or other multibyte encodings.

This isn't valid UTF-8.  A UTF-8 implementation MUST NOT decode these
octets, but MUST flag an error.  The most recent UTF-8 RFC is quite
explicit in this regard.

The UTF-8 issue I mentioned previously arises because Unicode has
additional characters with line-ending semantics.  There used to be a
Unicode Technical Report on this topic, but it has been superseded by
section 5.8 in Unicode 4.0:

  <http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf>

Date: Tue, 26 Oct 2004 16:52:54 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] Some capitalization oddities
Mail-Followup-To: [email-masked]
Sender: [email-masked]

In section 5.2.3.23, "User ID" is rendered as "user Id".

In sections 11.2, and 14, "key ID" is rendered as "key id".

Not an earth shattering problem, but consistency is nice (everywhere
else both of these items are consistent).

David

Date: Tue, 26 Oct 2004 16:47:58 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: [ISSUE] UTF-8 CRLF
Mail-Followup-To: [email-masked]
Sender: [email-masked]

The last sentence of section 5.9 reads:

  Text data is stored with <CR><LF> text endings (i.e. network-normal
  line endings).  These should be converted to native line endings by
  the receiving software.

Suggest to add:

  For the 'u' UTF8 literal packet, the minimal UTF8 encoding for the
  <CR><LF> line endings SHOULD be used.  That is, 0x0D 0x0A and not
  0xC0 0x8D 0xC0 0x8A or other multibyte encodings.

Rationale:

This would be a kindness for those implementations that will not be
doing UTF8->local conversions.  Lacking a UTF8 decoder, those
implementations cannot tell that "0xC0 0x8D" or other encodings is
identical to 0x0D.  If senders are careful in this regard, then the
non-UTF8 implementations can at least get the line endings right.

David

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: rfc2440bis-11  - 2 more comments
Date: Tue, 26 Oct 2004 13:26:14 -0700
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

On 23 Oct 2004, at 7:53 AM, Ian Grigg wrote:

>    "... Thus, software that
>    interoperates with those versions of PGP must only use old format
>    packets. If interoperability is not an issue, THE NEW PACKET FORMAT
>    IS PREFERRED."
>

Done.

> #2 Medium Comment
>      * The MD5 hash algorithm has been found to have weaknesses
>        (pseudo-collisions in the compress function) that make some
>        people deprecate its use.  They consider the SHA-1 algorithm
>        better.
>
> I think it's fair to say that since the last draft, we've
> moved on beyond that.  I'd suggest that MD5 should be deprecated.
> and applications SHOULD use SHA1 and for compatibility MAY
> accept MD5.  Or somesuch.
>

This is part of what I've glibly characterized as PGP 2 deprecation. No 
argument here.

> Now, that's either easy to say or hard to say, depending on
> whether one thinks that SHA1 is wobbly or safe.  But, on the
> whole, I don't think it should stop us deprecating MD5 at this
> point in time.  If that means that the document has a sort of
> hole in it, then so be it, mark it and let's move on.
>
> Before going on to deal with this - can we agree or discuss
> whether we should deprecate MD5 at this point?  If we agree
> to do so, then it's just a matter of scanning for MD5 and
> doing the switcheroo.
>

MD5 needs to be fully deprecated.

	Jon

From: Jon Callas <[email-masked]>
Subject: Re: last call?
Date: Tue, 26 Oct 2004 13:14:38 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I also want to issue my agreement with Werner on interoperability. 
Recent releases of GnuPG and PGP offer an existence proof of 
interoperability. (I'll go further and say that in the PGP cases, the 
interop problems we used to have were caused by our not upgrading 
pre-2440 behavior to be 2440-compliant.) The places where there *are* 
interop problems, they are caused by PGP 2 backwards compatibility. In 
2440, backwards compatibility is encouraged but not required; it's a 
SHOULD. Since one of the remaining items is to demote that SHOULD, we 
don't need to consider these issues. When you do this, Ian's 
implementation is a third one. There is interoperability.

	Jon

From: Jon Callas <[email-masked]>
Subject: Re: last call?
Date: Tue, 26 Oct 2004 13:05:04 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

I don't think we're ready for -11 to be last call.

As I've said before, what's missing from -11 is removing / deprecating 
/ etc. PGP 2 stuff. I haven't done that. That is in my opinion a 
requirement for last call.

Beyond that, I know of no remaining open issues (from the last time 
Derek and I talked) for which there was something actionable. I mean by 
'actionable' that while it might be true that X could be improved, 
there's no offered actual text. I'm loathe to go fix something that's 
suboptimal because there's a significant risk that my fix will be no 
better or even worse than the previous thing.

I offer as an example of where I did this in the past is the whitespace 
and trimming issue in text and clearsigned signatures. I took a good 
complaint with a reasonably vague description of what should be changed 
and made a good guess. That good guess wasn't good enough. I don't want 
to repeat this.

Restating again and tying in what Derek has said, he and I are going to 
be in the same place in a couple-three weeks. I believe there are no 
actionable open items. I believe that the remaining ones should be 
discarded, if for no other reason that they don't seem to be burning 
issues and finishing a new RFC takes precedence. (Modulo PGP 2 
deprecation) I'm willing to be corrected or overruled on either of my 
beliefs by him or the working group. But in the interests of finishing, 
I'm going to assert these beliefs in a clear voice.

	Jon

Date: Tue, 26 Oct 2004 12:42:04 +0100
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: last call?
Sender: [email-masked]

Derek Atkins wrote:

> Good question.  There is a document on the process in general,
> and "The Dao of the IETF".  As for when a 'bis' document progresses
> to Draft or stays at Proposed tends to be a combination of time,
> effort, interop, and the amount of changes between the original
> and new document.  In particular, to go from Proposed to Draft
> you generally can NOT add new features...

As an observation, I don't think too many features
have been added since 1999, so I can't see the
problem with that.

>>>Moving to "draft standard" will be a secondary process once we finish
>>>2440bis.
>>
>>:-(
>>
>>Okay, to make the later interop testing easier we should now really
>>consider to make all PGP2 things OPTIONAL or even remove them.

I personally think this is an excellent idea, but...

> Eh, we can always drop that when we move to draft.  Dropping
> "features" is perfectly reasonable in Proposed -> Draft.  The main
> purpose of the interop testing is to see what's been implemented but
> also to weed out what cannot be implemented (or hasn't been
> implemented) and drop it from the draft _then_.
> 
> So, if we're going to Proposed now, as I suspect we are, then there's
> no need to drop RFC1991 compatibility now.  We can drop in 6ish months
> later when we go to Draft.

That's encouraging.  Cryptix already made the decision
several years back to drop pgp2 from our OpenPGP library.

It just doesn't make sense to maintain separate paths in
the code for such a small user base, our users are much
better served with us spending that time on applications.

iang

To: Werner Koch <[email-masked]>
Cc: Ian Grigg <[email-masked]>, [email-masked]
Subject: Re: last call?
From: Derek Atkins <[email-masked]>
Date: Mon, 25 Oct 2004 14:20:52 -0400
Sender: [email-masked]

Werner Koch <[email-masked]> writes:

> On Mon, 25 Oct 2004 10:10:13 -0400, Derek Atkins said:
>
>> Unfortunately that is not sufficient....
>
> Is there an RFC defining the rules?  

Good question.  There is a document on the process in general,
and "The Dao of the IETF".  As for when a 'bis' document progresses
to Draft or stays at Proposed tends to be a combination of time,
effort, interop, and the amount of changes between the original
and new document.  In particular, to go from Proposed to Draft
you generally can NOT add new features...

> FWIW, from the minutes of the 45th IETF OpenPGP WG on 14-July-1999:
>
>   Advance to Draft, Collect $200
>      6 months have passed
>      Requirements
>        2 implementations
>        No IPR problems
>        6 months of experience
>   
>      JN: We have the experience but we do not have the interoperability
>      fully checked. Suggest: Enumerating all the musts and publishing a
>      document so implementors can easily see requirements for
>      compliance. Finally, we can get implementors into a room for
>      testing.
>   
>      Implementors' survey & results are at:
>        noc.rutgers.edu/~mione/ietf/ietfopgp.html

This was a long long time ago and under the previous chair, so my
applogies for not being in the loop for this.

>> Moving to "draft standard" will be a secondary process once we finish
>> 2440bis.
>
> :-(
>
> Okay, to make the later interop testing easier we should now really
> consider to make all PGP2 things OPTIONAL or even remove them.

Eh, we can always drop that when we move to draft.  Dropping
"features" is perfectly reasonable in Proposed -> Draft.  The main
purpose of the interop testing is to see what's been implemented but
also to weed out what cannot be implemented (or hasn't been
implemented) and drop it from the draft _then_.

So, if we're going to Proposed now, as I suspect we are, then there's
no need to drop RFC1991 compatibility now.  We can drop in 6ish months
later when we go to Draft.

>   Werner

-derek

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

To: Derek Atkins <[email-masked]>
Cc: Ian Grigg <[email-masked]>, [email-masked]
Subject: Re: last call?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 25 Oct 2004 19:36:22 +0200
Sender: [email-masked]

On Mon, 25 Oct 2004 10:10:13 -0400, Derek Atkins said:

> Unfortunately that is not sufficient....

Is there an RFC defining the rules?  

FWIW, from the minutes of the 45th IETF OpenPGP WG on 14-July-1999:

  Advance to Draft, Collect $200
     6 months have passed
     Requirements
       2 implementations
       No IPR problems
       6 months of experience
  
     JN: We have the experience but we do not have the interoperability
     fully checked. Suggest: Enumerating all the musts and publishing a
     document so implementors can easily see requirements for
     compliance. Finally, we can get implementors into a room for
     testing.
  
     Implementors' survey & results are at:
       noc.rutgers.edu/~mione/ietf/ietfopgp.html
  
> Moving to "draft standard" will be a secondary process once we finish
> 2440bis.

:-(

Okay, to make the later interop testing easier we should now really
consider to make all PGP2 things OPTIONAL or even remove them.

  Werner

To: Ian Grigg <[email-masked]>
Cc: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: last call?
From: Derek Atkins <[email-masked]>
Date: Mon, 25 Oct 2004 10:10:13 -0400
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:

> Werner Koch wrote:
>> On Mon, 25 Oct 2004 11:30:24 +0100, Ian Grigg said:
>
>>>2.  what is the process?  Do we vote, do we pray or do we
>>>send bribes?
>> We need to get a rough consensus within this WG.
>
> OK.  I'd say it is good to go.  With or without the handful
> of minor changes suggested in the last few days.

I'm glad you think it's good to go.  Being the chair, it's my job to
call a last call.  It's not going to happen before the DC meeting.  It
might happen shortly after DC.  I need to talk with Jon about it (I'll
be seeing him in about two weeks).

> Any other entries into consensual roughness?

Yes, we need to hear from lots of other people in this group, too, and
Jon and I need to go over the list of open issues and make sure they
are all handled.  Rough concensus is not one vocal person saying
"we're done", it's the group as a whole saying "we're done".  It's my
job to listen to the group as a whole..  And part of that job is
tuning _OUT_ those single vocal voices to make sure they aren't the
only ones saying something.

>> 5. How to we get into Draft Standard status?     We have talked for
>> years about interoperability tests but we never
>>    actually did anything.  AFAIK, there is no formal process for such
>>    a tests and I ask myself whether it is sufficient that the 2 oldest
>>    implementations (PGP and GnuPG) have shown over the years that they
>>    are quite good interoperable and that the last OpenPGP glitches
>>    have been sorted out with the last releases of both programs.  We
>>    could probably come up with a collection of discussions as evidence
>>    to what we have tested during the development.

Unfortunately that is not sufficient....

> OK, I am guessing here that interoperability tests
> are required to get to draft standard.

Yes.  However I believe 2440bis is still going to Proposed Standard.
There are enough changes to warrant PS instead of DS.

> a.  does that have a bearing on the RFC process for
> bis-11?  Or is it independent?

Moving to "draft standard" will be a secondary process once we finish
2440bis.

> b.  can someone summarise what has been said in the
> past about interoperability?

Irrelevant..  We need to work from the draft and perform an actual
bakeoff with multiple implementations and go, feature by feature down
the list in the draft and test each and every MUST/SHOULD in the
draft. (I don't recall if you need to test MAY, but I think you do).
Then you remove anything that hasn't been implemented, or you wait for
it to get imeplemented, and publish yet another draft (with yet
another RFC number) as a DS.

> c.  without any thought or research, I'd suggest
> something like the following:
>
>     i.  a program for each implementation that produced
>     an example of each type of message.
>
>     ii. a program for each that reads the examples in i.
>
>     iii. ideally, a service where an implementation can
>     be put into random spit mode, where it churns out
>     a squillion of these random messages of all forms,
>
>     iv. again, a service where an implementation can
>     process a squillion random messages.
>
> Then, take the two implementations and run them against
> each other.  (This is how I test my stuff.)  It has one
> particular hole in it, as it doesn't cover how an
> implementation deals with an illegal message.  But that's
> a security issue not an implementation issue.
>
> d.  or, anything else?

c is certainly a workable test plan..  But let's get 2440bis finished
before we start working on the bakeoff..  You're welcome to think
about how to implement the bakeoff now but I'd suggest we keep that to
a low simmer until we get the document through WGLC and into the hands
of the IESG.

> iang

-derek

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

Date: Mon, 25 Oct 2004 09:41:03 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: last call?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

>On Mon, Oct 25, 2004 at 01:49:06PM +0100, Ian Grigg wrote:

> >We need to get a rough consensus within this WG.
> 
> OK.  I'd say it is good to go.  With or without the handful
> of minor changes suggested in the last few days.
> 
> Any other entries into consensual roughness?

I am not part of such a consensus.  There were several minor open
issues when the list went silent.  I am traveling right now, but will
repost them tomorrow.

David

Date: Mon, 25 Oct 2004 13:49:06 +0100
From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
CC: [email-masked]
Subject: Re: last call?
Sender: [email-masked]

Werner Koch wrote:
> On Mon, 25 Oct 2004 11:30:24 +0100, Ian Grigg said:

>>2.  what is the process?  Do we vote, do we pray or do we
>>send bribes?
> 
> 
> We need to get a rough consensus within this WG.

OK.  I'd say it is good to go.  With or without the handful
of minor changes suggested in the last few days.

Any other entries into consensual roughness?

> 5. How to we get into Draft Standard status?  
> 
>    We have talked for years about interoperability tests but we never
>    actually did anything.  AFAIK, there is no formal process for such
>    a tests and I ask myself whether it is sufficient that the 2 oldest
>    implementations (PGP and GnuPG) have shown over the years that they
>    are quite good interoperable and that the last OpenPGP glitches
>    have been sorted out with the last releases of both programs.  We
>    could probably come up with a collection of discussions as evidence
>    to what we have tested during the development.

OK, I am guessing here that interoperability tests
are required to get to draft standard.

a.  does that have a bearing on the RFC process for
bis-11?  Or is it independent?

b.  can someone summarise what has been said in the
past about interoperability?

c.  without any thought or research, I'd suggest
something like the following:

    i.  a program for each implementation that produced
    an example of each type of message.

    ii. a program for each that reads the examples in i.

    iii. ideally, a service where an implementation can
    be put into random spit mode, where it churns out
    a squillion of these random messages of all forms,

    iv. again, a service where an implementation can
    process a squillion random messages.

Then, take the two implementations and run them against
each other.  (This is how I test my stuff.)  It has one
particular hole in it, as it doesn't cover how an
implementation deals with an illegal message.  But that's
a security issue not an implementation issue.

d.  or, anything else?

iang

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: last call?
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Mon, 25 Oct 2004 13:06:36 +0200
Sender: [email-masked]

On Mon, 25 Oct 2004 11:30:24 +0100, Ian Grigg said:

> 2.  what is the process?  Do we vote, do we pray or do we
> send bribes?

We need to get a rough consensus within this WG.

> 4.  What's the story about the RFC number change?  Is it
> possible to get an allocation at this point?

That is the task of the RFC-Editor.

5. How to we get into Draft Standard status?  

   We have talked for years about interoperability tests but we never
   actually did anything.  AFAIK, there is no formal process for such
   a tests and I ask myself whether it is sufficient that the 2 oldest
   implementations (PGP and GnuPG) have shown over the years that they
   are quite good interoperable and that the last OpenPGP glitches
   have been sorted out with the last releases of both programs.  We
   could probably come up with a collection of discussions as evidence
   to what we have tested during the development.

Salam-Shalom,

   Werner

Date: Mon, 25 Oct 2004 11:30:24 +0100
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: last call?
Sender: [email-masked]

It has been mooted that we might be moving to a last call for
changes on the draft bis-11 (perhaps only by me :-)

Questions of procedure:

1.  is this the case?  Are we entering into a last call?
And if not, how do we proceed to get there?

2.  what is the process?  Do we vote, do we pray or do we
send bribes?

3.  What is the procedure for doc changes within the process?
None at all?  Only severe security changes?  Or something
in between?

(I note that there seem to be at least 2 changes that have
to be made, being the year, I pointed out a few days ago,
and the RFC # which apparently has to change.)

4.  What's the story about the RFC number change?  Is it
possible to get an allocation at this point?

iang

Subject: private key binding clarification
Date: Mon, 25 Oct 2004 10:23:54 +0100
From: [email-masked]
To: [email-masked]
Sender: [email-masked]

5.2.4 p3: When a signature is made over a key, the
  hash data starts with the octet 0x99, followed by a
  two-octet length of the key, and then body of the
  key packet.

With respect to bindings in private key messages, I
think the last part should be changed to:

  '..length of the key, and then the public portion of
  the key packet body.'

-PK

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: Status of RFC2440
Date: Sun, 24 Oct 2004 12:08:34 +0200
Sender: [email-masked]

--nextPart1407073.pKzWvVF2ZB
Content-Type: text/plain;
  charset="iso-2022-jp"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Thursday 21 October 2004 04:01, Hironobu SUZUKI wrote:
> "X.509 is a standard". It is true because we have no any alternative
> choice for CA service in OpenPGP. It is hard to make OpenPGP CA
> service because there is no trust model with certificate authority in
> OpenPGP.

Actually, all the necessary flags are there:

section 5.2.3.12 Trust Signature  (can be used for sub-CA signature).

section 5/2.3.14 Revocation Key (necessary for some strictly hierachical CA=
=20
models).

section 5.2.3.20 Key Flags:
0x01 - this key may be used to certify other keys (read: Sub-CA)
0x02/0x04/0x08 - this key may be used to sign/encrypt data (read: user key)
0x10 - key escrow (minefield warning: partly patented by PGP Inc.)
0x80 - group key

All that is left to do is:
* implement support for this model in OpenPGP aware products
* issue a list of trusted CAs (public keyring) suitable for your application

	Konrad

--nextPart1407073.pKzWvVF2ZB
Content-Type: application/pgp-signature

--nextPart1407073.pKzWvVF2ZB--

Date: Sat, 23 Oct 2004 15:53:19 +0100
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: rfc2440bis-11  - 2 more comments
Sender: [email-masked]

#1. Minor comment

4.2 Packet Headers

    "... Thus, software that
    interoperates with those versions of PGP must only use old format
    packets. If interoperability is not an issue, either format may be
    used."

Setting it up for a future deprecation of the old format
may be useful.  In which case, it could be advantageous to
prefer the new format.  Some example text:

    "... Thus, software that
    interoperates with those versions of PGP must only use old format
    packets. If interoperability is not an issue, THE NEW PACKET FORMAT
    IS PREFERRED."

#2 Medium Comment

13. Security Considerations
      ...
      * The MD5 hash algorithm has been found to have weaknesses
        (pseudo-collisions in the compress function) that make some
        people deprecate its use.  They consider the SHA-1 algorithm
        better.

I think it's fair to say that since the last draft, we've
moved on beyond that.  I'd suggest that MD5 should be deprecated.
and applications SHOULD use SHA1 and for compatibility MAY
accept MD5.  Or somesuch.

Now, that's either easy to say or hard to say, depending on
whether one thinks that SHA1 is wobbly or safe.  But, on the
whole, I don't think it should stop us deprecating MD5 at this
point in time.  If that means that the document has a sort of
hole in it, then so be it, mark it and let's move on.

Before going on to deal with this - can we agree or discuss
whether we should deprecate MD5 at this point?  If we agree
to do so, then it's just a matter of scanning for MD5 and
doing the switcheroo.

iang

[email-masked] wrote:

> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-11.txt

Date: Fri, 22 Oct 2004 23:08:27 +0100
From: Ian Grigg <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-11.txt
Sender: [email-masked]

Expires Apr 20, 2004

> 	Title		: OpenPGP Message Format
> 	Author(s)	: J. Callas, et al.
> 	Filename	: draft-ietf-openpgp-rfc2440bis-11.txt
> 	Pages		: 72
> 	Date		: 2004-10-22

The version I just downloaded says on every page:

     Expires Apr 20, 2004

Shouldn't that be 2005?

iang

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-11.txt
Date: Fri, 22 Oct 2004 16:01:12 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: OpenPGP Message Format
	Author(s)	: J. Callas, et al.
	Filename	: draft-ietf-openpgp-rfc2440bis-11.txt
	Pages		: 72
	Date		: 2004-10-22
	
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage.  These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-11.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-rfc2440bis-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-11.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-rfc2440bis-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Request for Agenda Items for DC IETF
Date: Thu, 21 Oct 2004 13:45:11 -0700
To: Derek Atkins <[email-masked]>
Sender: [email-masked]

On 21 Oct 2004, at 8:35 AM, Derek Atkins wrote:

>
> Hi,
>
> I plan to request a 1hour slot at the DC IETF so we can wrap up
> 2440bis (hopefully).  Anyone have any agenda items they'd like to
> discuss at the meeting?
>

My opinion is that we don't need the slot. The few things we need to 
cover can (and should) be handled here. We're not the sort of group 
that needs face time. I am unlikely to be able to make it there, and 
anything that goes on there will have to happen here, too, so it just 
consumes more time to have the meeting.

	Jon

To: [email-masked]
Subject: Request for Agenda Items for DC IETF
From: Derek Atkins <[email-masked]>
Date: Thu, 21 Oct 2004 11:35:42 -0400
Sender: [email-masked]

Hi,

I plan to request a 1hour slot at the DC IETF so we can wrap up
2440bis (hopefully).  Anyone have any agenda items they'd like to
discuss at the meeting?

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

To: Ian Grigg <[email-masked]>
Cc: Jon Callas <[email-masked]>, [email-masked]
Subject: Re: Status of RFC2440
From: Derek Atkins <[email-masked]>
Date: Thu, 21 Oct 2004 11:27:38 -0400
Sender: [email-masked]

Ian Grigg <[email-masked]> writes:

> Jon Callas wrote:
>>
>>>
>>> I've been asked to speak at an Identity
>>> conference and while I was musing on the
>>> unsuitability of x.509/PKI for identity,
>>> it occurred to me that one of the barriers
>>> is that OpenPGP is not a standard, whereas
>>> x.509 is.
>>>
>> Huh? OpenPGP isn't a standard? How?
>
> Specifically (bearing in mind the emphasis
> outlined below on mindspace) we lack the completed
> RFC.  That will be a big help.

Uhh, define "completed RFC".  RFC2440 is completed, has been for
several years.  It's also an RFC.  It will always be an RFC.  RFC2440
will never change!  

<chair-hat>
There's the ongoing rfc2440bis work, which will hopefully complete
soon and get turned into a new RFC with a new RFC number and will
obsolete RFCs 1991 and 2440.  But that does not obviate the fact that
RFC 2440 is a published Proposed Standard on OpenPGP.
</chair-hat>

So, your statement that "OpenPGP is not a standard" is clearly
incorrect.

-derek

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

Date: Thu, 21 Oct 2004 15:54:15 +0100
From: Ian Grigg <[email-masked]>
To: Jon Callas <[email-masked]>
CC: [email-masked]
Subject: Re: Status of RFC2440
Sender: [email-masked]

Jon Callas wrote:
> 
>>
>> I've been asked to speak at an Identity
>> conference and while I was musing on the
>> unsuitability of x.509/PKI for identity,
>> it occurred to me that one of the barriers
>> is that OpenPGP is not a standard, whereas
>> x.509 is.
>>
> 
> Huh? OpenPGP isn't a standard? How?

Specifically (bearing in mind the emphasis
outlined below on mindspace) we lack the completed
RFC.  That will be a big help.

> In the last couple of years there's been a resurgence of OpenPGP-based 
> systems. I see new ones coming on line (usually in an email that says 
> something like, "Is this a competitor of yours?") about at the rate of 
> one every month or two, but I've gotten two of them this *week*. More 
> than one of these new people have contributed here. If anything, OpenPGP 
> is undergoing a renaissance right now. There are also other bits of 
> ground breaking on further adoption that I can't talk about, but I can 
> tell you that I don't see this pattern stopping.

Well that's encouraging news.  Is there any way
we can get a picture on how many ventures out there
are building RFC2440 systems?

That's an open question!  It would be nice
if there was a list or a forum of apps or a group
of people doing stuff.  (There is this group, which
is strictly standards focused, and the cryptorights
mailing list that I am aware of.)

> My products support both OpenPGP and X.509, and my official policy is to 
> be format agnostic. However, I'll say that while X.509 is a "standard" 
> it is a "standard" that you often have to make work by doing passive 
> fingerprinting on the certs. You look at it, infer what software or CA 
> created it, and special case the handling of the crypto system 
> accordingly. I'm not complaining, merely stating. For anyone who goes to 
> the trouble of walking the minefield of X.509 interoperability, this 
> "standard" is a huge barrier to entry to competition. Unlike OpenPGP, 
> where someone can knock off an interoperable system with a little bit of 
> work (hacking, if necessary your own previous systems and others like 
> the Perl module) and end up with something that works, X.509 takes 
> *work* to make interoperate, and this is a huge boon for anyone who 
> actually makes a living at this.

Everything you say makes sense.  But when I was
mentioning barriers to entry, I was specifically
thinking in terms of the institutional mindset.
x.509 to them is telecoms, ISO, Verisign, billion
dollar companies, and all the associated mindspace
and presence that goes with a standard.

Whereas OpenPGP is .. what?  A bunch of net geeks
mucking around with crypto mail.  When they're
not fighting the government they're fighting
each other...

In those terms, which are the terms that any
company over a thousand employees buys on, x.509
is a standard, and OpenPGP is a frontier toy.
These people have no capability to drill down
through the sales blurb into what the software
does, or the crypto does.  These are the people
who say "it is a standard if IBM says it is a
standard."

> Yes, yes, there are open source toolkits for X.509. I've used them. My 
> conclusion was that those nice folks at GeoTrust provide a good service 
> for the money, especially when I compute my own hourly rate and the fact 
> that I could otherwise be doing something fun.
> 
> Be sure to tell them that, when you talk about the superiority of 
> "standards" to mere RFCs. :-)

Oh, don't get me wrong - my part is on how to
fix the broken x.509 models / how the RFC2440
model has delivered.  But I feel it is important
to try and work out why it is that these big buyers
simply don't see the alternates.  One of the
answers is their mindset that the x.509 thing
is a standard.  And there isn't any competition
to that mindspace.

Not yet.  Hence my suggestion that we start calling
it RFC2440 rather than OpenPGP.  (I'm throwing that
out there more to point people at the issues rather
than expecting it to be a valuable idea.)

iang

Date: Thu, 21 Oct 2004 15:34:47 +0100
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: Status of RFC2440
Sender: [email-masked]

Hironobu,

Just some comments, while the list is quiet and
awaiting the "last call!"

You seem to be grasping on a definition of trust.

OpenPGP does not define what the meaning of signatures
from one user's key to another is.  That is, if I sign
your key, there is no meaning defined by the tech to
what my signature should convey.

That's because it is too difficult to do at that level.

x.509/CA technologies try to do just that: define trust,
and they fail miserably.  They fail at defining trust
for many many reasons, chief amongst which is that
trust is a human quality that defies categorisation
in bits and bytes.

So in actuality your comments apply more to the x.509
and CA model:  they are not effective for trust.
They push something they call "trust" but its only
relationship with the word we humans share is its
spelling.

Now recast to RFC2440 / OpenPGP.  This technology is
totally neutral to trust.  It is neither effective nor
ineffective - it simply doesn't define that.  What it
does do is provide a linking capability - from key to
key - which is ideally aligned and suitable for mapping
human, social and commerce patterns.

(So, the web of trust is misnamed.  It should be the
web of links, or the web of relationships, or similar
neutral terms.)

Which is to say, if you have a vision of trust, you
can build it in RFC2440.  You won't be able to build
it in x.509, because they already cast their "trust"
in concrete and got it wrong.

But, that's up to you - RFC2440 awaits your notions.
Build and see if it works.  I would however suggest
that you not rely on the word "trust."  That's a word
that belongs in each and every person's head, not in
tech.

iang

From: Hironobu SUZUKI <[email-masked]>
To: [email-masked]
Subject: Re: Status of RFC2440 
Date: Thu, 21 Oct 2004 11:01:04 +0900
Sender: [email-masked]

I'd like to write my comments.

"X.509 is a standard". It is true because we have no any alternative
choice for CA service in OpenPGP. It is hard to make OpenPGP CA
service because there is no trust model with certificate authority in
OpenPGP.

Current version of "Web of Trust" is not effective for
trustworthiness. See "Web of Trust" in Debian project. It looks as
like "autograph please", "I have more autographs than you".

But "Web of Trust" model is very flexible way and it has potential to
make OpenPGP based CA model. I understand that OpenPGP based CA
service must be there also.

Please note that OpenPGP based CA service must be not only business
domain but also community domain. Organizations, companies, school,
class, projects and any size of community may have their own CA.  It
should be compared with "Student ID", "Member ID" and "Backstage
ID". It should not be compared with "Passport ID", "Nation ID" and
"Social ID". Fair identification is necessary for our life.

Today, X.509 with OpenPGP is practical solution but ultimate solution
is to make OpenPGP's "Web of Trust" model with certificate authority
for our community.  X.509 is OK but I'd would like to seek "something
new for OpenPGP".

I have a plan to make "Trusted Public Keyserver" that can provide
public keys that owner-allowed to open public. Many public keys in
public keyserver have garbage signatures and many OpenPGP users put
their "please use this" public key in their web site, not public
keyserver. OpenPKSD-TPK will be my answer. Finish this plan, I'd like
to design "Trust model with OpenPGP based CA" and to implement it.

I believe that the diversity is required to survive, is not the first
step to the chaos.

Regards,

--- 
Hironobu SUZUKI  (From Japan)
E-Mail: hironobu @ h2np.net
URL: http://h2np.net
URL: http://openpksd.org

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Status of RFC2440
Date: Wed, 20 Oct 2004 11:33:24 -0700
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

>
> I've been asked to speak at an Identity
> conference and while I was musing on the
> unsuitability of x.509/PKI for identity,
> it occurred to me that one of the barriers
> is that OpenPGP is not a standard, whereas
> x.509 is.
>

Huh? OpenPGP isn't a standard? How?

In the last couple of years there's been a resurgence of OpenPGP-based 
systems. I see new ones coming on line (usually in an email that says 
something like, "Is this a competitor of yours?") about at the rate of 
one every month or two, but I've gotten two of them this *week*. More 
than one of these new people have contributed here. If anything, 
OpenPGP is undergoing a renaissance right now. There are also other 
bits of ground breaking on further adoption that I can't talk about, 
but I can tell you that I don't see this pattern stopping.

My products support both OpenPGP and X.509, and my official policy is 
to be format agnostic. However, I'll say that while X.509 is a 
"standard" it is a "standard" that you often have to make work by doing 
passive fingerprinting on the certs. You look at it, infer what 
software or CA created it, and special case the handling of the crypto 
system accordingly. I'm not complaining, merely stating. For anyone who 
goes to the trouble of walking the minefield of X.509 interoperability, 
this "standard" is a huge barrier to entry to competition. Unlike 
OpenPGP, where someone can knock off an interoperable system with a 
little bit of work (hacking, if necessary your own previous systems and 
others like the Perl module) and end up with something that works, 
X.509 takes *work* to make interoperate, and this is a huge boon for 
anyone who actually makes a living at this.

Yes, yes, there are open source toolkits for X.509. I've used them. My 
conclusion was that those nice folks at GeoTrust provide a good service 
for the money, especially when I compute my own hourly rate and the 
fact that I could otherwise be doing something fun.

Be sure to tell them that, when you talk about the superiority of 
"standards" to mere RFCs. :-)

	Jon

Date: Wed, 20 Oct 2004 19:32:05 +0100
From: Ian Grigg <[email-masked]>
To: Jon Callas <[email-masked]>
CC: Werner Koch <[email-masked]>, [email-masked]
Subject: Re: Status of RFC2440
Sender: [email-masked]

Jon,

Excellent news!  can you post a URL for us when it
is up there.  Thanks,

iang

Jon Callas wrote:

> Sorry. I just sent out my latest version as bis-12.
> 
> What's left, to my mind, is for me to go and fully deprecate V3 keys / 
> MD5. When I last looked at open issues with Derek, I'd put in words for 
> all issues anyone had where there was something actionable. After that, 
> as far as I'm concerned, we can put this into real last call.

Yes, kill the V3.  Less is better.

iang

Cc: [email-masked], Ian Grigg <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: Status of RFC2440
Date: Wed, 20 Oct 2004 11:02:35 -0700
To: Werner Koch <[email-masked]>
Sender: [email-masked]

>> What is the status of the OpenPGP draft?
>
> IIRC, the latest draft has expired and is thus not anymore available
> from the usual places.
>

Sorry. I just sent out my latest version as bis-12.

What's left, to my mind, is for me to go and fully deprecate V3 keys / 
MD5. When I last looked at open issues with Derek, I'd put in words for 
all issues anyone had where there was something actionable. After that, 
as far as I'm concerned, we can put this into real last call.

	Jon

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Status of RFC2440
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 20 Oct 2004 13:40:23 +0200
Sender: [email-masked]

On Wed, 20 Oct 2004 11:38:04 +0100, Ian Grigg said:

> Oh, indeed.  BTW, do you have any statistics on that?

Sorry no.  I have not seen that companies publically announce that
they now use encryption for their communication; probably because
everyone would expects that communication is held confidential.

> a third is reputation.  Both of these are relatively
> well served by the OpenPGP's web of trust, but they
> are being ignored.  Meanwhile, a lot of companies

There are no widely used applications to support OpenPGP for that.  I
know one TLS implementaion capable of using OpenPGP keys but the usual
web clients don't support it. 

It would be easy to use this with ssh and I expect to see it in the
near future.

> normally start with "why o why is there no button to
> generate a self-signed x.509 key and start using it?"

Even worse: My jabber client complains about self-signed certificates
instead of displaying its fingerprint once for verification.

> But, to underscore my earlier point, mail is not where
> it's at.  Traffic is moving to chat, and there is a
> chance to re-engineer the comms architecture, as chat

Although I don't like chat things very much, you are probably right.

Salam-Shalom,

   Werner

Date: Wed, 20 Oct 2004 11:38:04 +0100
From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
CC: [email-masked]
Subject: Re: Status of RFC2440
Sender: [email-masked]

Werner Koch wrote:
> On Wed, 20 Oct 2004 10:23:23 +0100, Ian Grigg said:

>>the market, it has the support of all the major
>>players, whereas rfc2440 has not, and it has the
>>ISO label.  All of these things equate to "it's
> 
> 
> With respect to email encryption OpenPGP is the standard protocol most
> people want to go with because it is kown to work.  At least this is
> what I hear from companies looking into ways to encrypt email. 

Oh, indeed.  BTW, do you have any statistics on that?
It would be very useful to get some hard or soft
figures on it, because we continually come up against
people believe their own world is the only world.

But, my point is not about mail.  Mail is but one
application of OpenPGP.  Another is identity, and
a third is reputation.  Both of these are relatively
well served by the OpenPGP's web of trust, but they
are being ignored.  Meanwhile, a lot of companies
have been trying for years to do identity in x.509
and failing dismally because of the constraints in
that technology, and I don't think it is even
possible to do reputation in x.509.

> I only MS Outlook would allow to set the content-type explicitly - to
> implement PGP/MIME - the remaining deployment problem would be
> solvable.

There's a lot wrong with Internet mail programs.  I
normally start with "why o why is there no button to
generate a self-signed x.509 key and start using it?"

But, to underscore my earlier point, mail is not where
it's at.  Traffic is moving to chat, and there is a
chance to re-engineer the comms architecture, as chat
is still an open market with competing protocols.  So
not being standard is not a draw back.  The only thing
of importance is whether it works and deploys quickly,
and OpenPGP has a much better chance of that than any
alternate.

iang

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Status of RFC2440
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 20 Oct 2004 11:55:47 +0200
Sender: [email-masked]

On Wed, 20 Oct 2004 10:23:23 +0100, Ian Grigg said:

> the market, it has the support of all the major
> players, whereas rfc2440 has not, and it has the
> ISO label.  All of these things equate to "it's

With respect to email encryption OpenPGP is the standard protocol most
people want to go with because it is kown to work.  At least this is
what I hear from companies looking into ways to encrypt email. 

I only MS Outlook would allow to set the content-type explicitly - to
implement PGP/MIME - the remaining deployment problem would be
solvable.

Shalom-Salam,

   Werner

Date: Wed, 20 Oct 2004 10:23:23 +0100
From: Ian Grigg <[email-masked]>
To: Werner Koch <[email-masked]>
CC: [email-masked]
Subject: Re: Status of RFC2440
Sender: [email-masked]

Werner Koch wrote:
> On Tue, 19 Oct 2004 21:53:26 +0100, Ian Grigg said:
> 
> 
>>What is the status of the OpenPGP draft?
> 
> 
> IIRC, the latest draft has expired and is thus not anymore available
> from the usual places.
> 
> 
>>it occurred to me that one of the barriers
>>is that OpenPGP is not a standard, whereas
>>x.509 is.
> 
> 
> I just checked the rfc-index and both, OpenPGP (rfc2440) and X.509
> PKIX profile (rfc3280), are in PROPOSED STANDARD status.  You don't
> want to call plain ISO X.509 a practically useful standard without
> specifying a profile.

Me, I wouldn't call x.509 practically useful in
any contexts ;-)  But the point is that it has
the market, it has the support of all the major
players, whereas rfc2440 has not, and it has the
ISO label.  All of these things equate to "it's
a standard" without much drilling down into what
that means.

> We talked about moving to DRAFT status since mid 1999 with no result
> though. Derek, any new plans on moving forward?

Yes, I don't understand it.  As I understand,
about a year ago it was feature frozen, and a
list of issues had to be cleaned up.

iang

To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Status of RFC2440
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
Date: Wed, 20 Oct 2004 09:30:12 +0200
Sender: [email-masked]

On Tue, 19 Oct 2004 21:53:26 +0100, Ian Grigg said:

> What is the status of the OpenPGP draft?

IIRC, the latest draft has expired and is thus not anymore available
from the usual places.

> it occurred to me that one of the barriers
> is that OpenPGP is not a standard, whereas
> x.509 is.

I just checked the rfc-index and both, OpenPGP (rfc2440) and X.509
PKIX profile (rfc3280), are in PROPOSED STANDARD status.  You don't
want to call plain ISO X.509 a practically useful standard without
specifying a profile.

We talked about moving to DRAFT status since mid 1999 with no result
though. Derek, any new plans on moving forward?

Shalom-Salam,

   Werner

Date: Tue, 19 Oct 2004 21:53:26 +0100
From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Status of RFC2440
Sender: [email-masked]

What is the status of the OpenPGP draft?

I've been asked to speak at an Identity
conference and while I was musing on the
unsuitability of x.509/PKI for identity,
it occurred to me that one of the barriers
is that OpenPGP is not a standard, whereas
x.509 is.

Institutions put great store on standards
(rightly or wrongly).  Also, the "PGP" name
is considered somewhat to be loony in many
staid quarters.  It would be thus doubly
good to have a completed spec, so that we
could say that a system conformed to RFC
2440, an internet identity architecture
standard.

(With all the normal marketing caveats of
course!)

iang