OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-22

[Ballot discuss]
An updated discuss note:

1. First of all I think the spec is hard to implement from. But based on the existance of implementation I can go to an abstain in regards to the difficulties to implement it.

2. I still like to have an answer why the WG hasn't considered to tighten up the specification for the decoder behavior to promote interoperability.  My reasoning and an example of this untightness is below.

OpenPGP is used in system where sender and receiver do not have the possibility to negotiate feauter support prior to sending a message. Due to this I would expect very tight definitions on what must be implemented in receivers of openPGP. But already in section 2 it is made cleared that a lot of important and fundamental mechanisms like compression and RADIX-64 support is not mandated, only recommeded. As I see it this is one of the cases is where the decoder specification is the most important. As long as the encoder creates something that a standard compliant decoder can decode things are fine. The Feature option helps somewhat, but still think there is need for improvement here.

I don't see specifying the decoder in this fashion will have any impact on the compatibility with the deployed base. The compatibility comes into encoding recommendations. And you already have profiles over recommend set of behavior to get interoperability given the knowledge about receivers and their levels. However without a tight decoder spec one will never in the future be able to go beyond the recommend sets even when knowing that the decoder will be following this specification.

If the WG has reasons why they can't be better specified, please inform me.

Section 5.2.3.1:
  "An implementation SHOULD ignore any subpacket of a type that it does
    not recognize."

This is one more point where interoperability problems arise due to too loose specifications. Either one ignore or not unknowns types. Only knowing what will happen in a receiver can one dare to deploy new sub packet types. Especially considering that you have a mechanism to indicate that sub packet types must be understood I don't understand why tighter language has not been used. To me it seems that the specification should be written in the following form:

subpacket types SHALL be ignored unless the "critical" indicator is set, in which case an error SHALL be generated.

[Ballot discuss]
This is a DISCUSS discuss.  My apologies for its length...

This document would benefit from additional information on cryptographic key sizes.  For
algorithms that may use a range of key sizes, the document specifies a minimum (e.g., section
13.5 states "An implementation SHOULD NOT implement RSA keys of size less than 1024 bits.")
However, it does not make any further requirements.

Two conforming implementations could be developed - one that processed only 1024 bit
signatures, and a second that processed only 2048 bit signatures - and they would not
interoperate.  I admit this is a bit of a stretch but it plays into a more realistic scenario of
great concern to me.    Current guidance from a number of sources (including RFC 3766,
NIST's cryptographers, etc.) indicates that 1024 bit cryptography should be phased out.
Consider the case where the reciever has an implementation that only supports 1024 bit keys,
but the sender uses 2048 bit keys for signing messages, based on that guidance.

If I purchase a conforming implementation that only suports 1024 bit keys, I may not be able
to communicate with many organizations in the very near future. Consider it a standards
compliant denial of service attack!  In my opinion, this specification should encourage
implementers to support broad ranges of key sizes, especially for RSA and DSA.  I understand
that this is not normal IETF procedure, but I believe that key size agility is important.

At a minimum, I would like to see this concept appear in the security considerations.  It
might be convenient to present the concept after the table of equivalent symmetric key
strengths from [SP800-57] is given.  Establishing a range of MUST implement key sizes
would be better, but may adversely impact implementations for small footprint devices.

[Ballot discuss]
I do agree with Lars about that this specification will not produce interoperable implementations, but maybe not for the same reasons.

OpenPGP is used in system where sender and receiver do not have the possibility to negotiate feauter support prior to sending a message. Due to this I would expect very tight definitions on what must be implemented in receivers of openPGP. But already in section 2 it is made cleared that a lot of important and fundamental mechanisms like compression and RADIX-64 support is not mandated, only recommeded. As I see it this is one of the cases is where the decoder specification is the most important. As long as the encoder creates something that a standard compliant decoder can decode things are fine. The Feature option helps somewhat, but still think there is need for improvement here.

I don't see specifying the decoder in this fashion will have any impact on the compatibility with the deployed base. The compatibility comes into encoding recommendations. And you already have profiles over recommend set of behavior to get interoperability given the knowledge about receivers and their levels. However without a tight decoder spec one will never in the future be able to go beyond the recommend sets even when knowing that the decoder will be following this specification.

If the WG has reasons why they can't be better specified, please inform me.

Section 5.2.3.1:
  "An implementation SHOULD ignore any subpacket of a type that it does
    not recognize."

This is one more point where interoperability problems arise due to too loose specifications. Either one ignore or not unknowns types. Only knowing what will happen in a receiver can one dare to deploy new sub packet types. Especially considering that you have a mechanism to indicate that sub packet types must be understood I don't understand why tighter language has not been used. To me it seems that the specification should be written in the following form:

subpacket types SHALL be ignored unless the "critical" indicator is set, in which case an error SHALL be generated.

section 6:

    OpenPGP's Radix-64 encoding is composed of two parts: a base64
    encoding of the binary data, and a checksum. The base64 encoding is
    identical to the MIME base64 content-transfer-encoding [RFC2045].

Shouldn't this specification use RFC 4648 as reference for base64 encoding?

[Ballot discuss]
I do agree with Lars about that this specification will not produce interoperable implementations, but maybe not for the same reasons.

OpenPGP is used in system where sender and receiver do not have the possibility to negotiate feauter support prior to sending a message. Due to this I would expect very tight definitions on what must be implemented in receivers of openPGP. But already in section 2 it is made cleared that a lot of important and fundamental mechanisms like compression and RADIX-64 support is not mandated, only recommeded. As I see it this is one of the cases is where the decoder specification is the most important. As long as the encoder creates something that a standard compliant decoder can decode things are fine. The Feature option helps somewhat, but still think there is need for improvement here.

I don't see specifying the decoder in this fashion will have any impact on the compatibility with the deployed base. The compatibility comes into encoding recommendations. And you already have profiles over recommend set of behavior to get interoperability given the knowledge about receivers and their levels. However without a tight decoder spec one will never in the future be able to go beyond the recommend sets even when knowing that the decoder will be following this specification.

If the WG has reasons why they can't be better specified, please inform me.

Section 5.2.3.1:
  "An implementation SHOULD ignore any subpacket of a type that it does
    not recognize."

This is one more point where interoperability problems arise due to too loose specifications. Either one ignore or not unknowns types. Only knowing what will happen in a receiver can one dare to deploy new sub packet types. Especially considering that you have a mechanism to indicate that sub packet types must be understood I don't understand why tighter language has not been used. To me it seems that the specification should be written in the following form:

subpacket types SHALL be ignored unless the "critical" indicator is set, in which case an error SHALL be generated.

section 6:

    OpenPGP's Radix-64 encoding is composed of two parts: a base64
    encoding of the binary data, and a checksum. The base64 encoding is
    identical to the MIME base64 content-transfer-encoding [RFC2045].

Shouldn't this specification use RFC 4648 as reference for base64 encoding?

Downref:

The Reference to RFC 1991 hasn't been handled correctly. However it seems that the usage in RFC 1991 is informational and the reference could be moved.

[Ballot discuss]
I do agree with Lars about that this specification will not produce interoperable implementations, but maybe not for the same reasons.

OpenPGP is used in system where sender and receiver do not have the possibility to negotiate feauter support prior to sending a message. Due to this I would expect very tight definitions on what must be implemented in receivers of openPGP. But already in section 2 it is made cleared that a lot of important and fundamental mechanisms like compression and RADIX-64 support is not mandated, only recommeded. As I see it this is one of the cases is where the decoder specification is the most important. As long as the encoder creates something that a standard compliant decoder can decode things are fine. The Feature option helps somewhat, but still think there is need for improvement here.

I don't see specifying the decoder in this fashion will have any impact on the compatibility with the deployed base. The compatibility comes into encoding recommendations. And you already have profiles over recommend set of behavior to get interoperability given the knowledge about receivers and their levels. However without a tight decoder spec one will never in the future be able to go beyond the recommend sets even when knowing that the decoder will be following this specification.

If the WG has reasons why they can't be better specified, please inform me.

Section 5.2.3.1:
  "An implementation SHOULD ignore any subpacket of a type that it does
    not recognize."

This is one more point where interoperability problems arise due to too loose specifications. Either one ignore or not unknowns types. Only knowing what will happen in a receiver can one dare to deploy new sub packet types. Especially considering that you have a mechanism to indicate that sub packet types must be understood I don't understand why tighter language has not been used. To me it seems that the specification should be written in the following form:

subpacket types SHALL be ignored unless the "critical" indicator is set, in which case an error SHALL be generated.

section 6:

    OpenPGP's Radix-64 encoding is composed of two parts: a base64
    encoding of the binary data, and a checksum. The base64 encoding is
    identical to the MIME base64 content-transfer-encoding [RFC2045].

Shouldn't this specification use RFC 4648 as reference for base64 encoding?

[Ballot discuss]
This is a DISCUSS discuss.  My apologies for its length...

This document would benefit from additional information on cryptographic key sizes.  For
algorithms that may use a range of key sizes, the document specifies a minimum (e.g., section
13.5 states "An implementation SHOULD NOT implement RSA keys of size less than 1024 bits.")
However, it does not make any further requirements.

Two conforming implementations could be developed - one that processed only 1024 bit
signatures, and a second that processed only 2048 bit signatures - and they would not
interoperate.  I admit this is a bit of a stretch but it plays into a more realistic scenario of
great concern to me.    At NIST, we are mandating migration to 2048 bit keys by the end of
2010.  Migration needs to be completed by that date, so new key pairs for most applications
will be 2048 bits starting in January.

If I purchase a conforming implementation that only suports 1024 bit keys, I may not be able
to communicate with many organizations in the very near future. Consider it a standards
compliant denial of service attack!  In my opinion, this specification should encourage
implementers to support broad ranges of key sizes, especially for RSA and DSA.  I understand
that this is not normal IETF procedure, but I believe that key size agility is important.

At a minimum, I would like to see this concept appear in the security considerations.  It
might be convenient to present the concept after the table of equivalent symmetric key
strengths from [SP800-57] is given.  Establishing a range of MUST implement key sizes
would be better, but may adversely impact implementations for small footprint devices.

[Ballot discuss]
This is a DISCUSS discuss.  My apologies for its length...

This document would benefit from additional information on cryptographic key sizes.  For
algorithms that may use a range of key sizes, the document specifies a minimum (e.g., section
13.5 states "An implementation SHOULD NOT implement RSA keys of size less than 1024 bits.")
However, it does not make any further requirements.

Two conforming implementations could be developed - one that processed only 1024 bit
signatures, and a second that processed only 2048 bit signatures - and they would not
interoperate.  I admit this is a bit of a stretch but it plays into a more realistic scenario of
great concern to me.    At NIST, we are mandating migration to 2048 bit keys by the end of
2010.  Migration needs to be completed by that date, so new key pairs for most applications
will be 2048 bits starting in January.

If I purchase a conforming implementation that only suports 1024 bit keys, I may not be able
to communicate with many organizations in the very near future. Consider it a standards
compliant denial of service attack!  In my opinion, this specification should encourage
implementers to support broad ranges of key sizes, especially for RSA and DSA.  I understand
that this is not normal IETF procedure, but I believe that key size agility is important.

At a minimum, I would like to see this concept appear in the security considerations.  It might be convenient to present the concept after the table of equivalent symmetric key strengths
from [SP800-57] is given.  Establishing a range of MUST implement key sizes would be better,
but may adversely impact implementations for small footprint devices.

[Ballot discuss]
This is a DISCUSS discuss.  My apologies for its length...

This document would benefit from additional information on cryptographic key sizes.  For
algorithms that may use a range of key sizes, the document specifies a minimum (e.g., section
13.5 states "An implementation SHOULD NOT implement RSA keys of size less than 1024 bits.")
However, it does not make any further requirements.

Two conforming implementations could be developed - one that processed only 1024 bit
signatures, and a second that processed only 2048 bit signatures - and they would not
interoperate.  I admit this is a bit of a stretch but it plays into a more realistic scenario of
great concern to me.    At NIST, we are mandating migration to 2048 bit keys by the end of
2010.  That is a completed migration, so new key pairs will be 2048 bits starting in January.

If I purchase a conforming implementation that only suports 1024 bit keys, I may not be able
to communicate with many organizations in the very near future. Consider it a standards
compliant denial of service attack!  In my opinion, this specification should encourage
implementers to support broad ranges of key sizes, especially for RSA and DSA.  I understand
that this is not normal IETF procedure, but I believe that key size agility is important.

I would suggest adding this into the security considerations, after the table of equivalent
symmetric key strengths from [SP800-57] is given.

[Ballot comment]
I'm abstaining from this document. I believe that it is impossible to develop an interoperable OpenPGP implementation based on this document, because it merely defines a packet format without explaining the semantics of the various fields in a way that would let an implementor design the required program logic. I'm not aware of a companion document that includes that content, either. It is in my opinion inappropriate to publish this document as a Proposed Standard for this reason. I would have no objection with publishing this document as Informational or maybe even Historic.

[Ballot comment]
Some comments come from the Gen-ART review by Miguel Garcia.

  These two paragraphs should include references for RFC 2119 and
  RFC 2434:
  >
  > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  > document are to be interpreted as described in RFC 2119.
  >
  > The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
  > FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
  > APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in
  > this document when used to describe namespace allocation are to be
  > interpreted as described in RFC 2434.
  >
  There are other RFCs that are referenced by number without including
  the appropriate reference (RFC 1991 is an example).
 
  The document contains this reference [RFC 1950], but it is not included
  in the references.

[Ballot comment]
The clear signature format in section 7 causes signature crud to appear
in mail readers that do not support PGP.  It's my belief that such "crud"
can be harmful to deployment of technology (e.g., user A starts using
PGP sends signed mail to user B who doesn't use PGP but sees lots of
PGP boilerplate around the email so user B complains to user A about this
and user A decides PGP is too much trouble).  As the IETF has
standardized a mechanism (RFC 3156) which allows mail clients to suppress
most of the "crud," and this mechanism allows a single piece of code to
gracefully handle both PGP and S/MIME, it's my belief we should recommend
greater use of that mechanism to help support greater deployment of
secure email technology.

An additional benefit of RFC 3156 is gateways that alter whitespace or
encodings will keep their hands off that part of the message in a way
they might not otherwise.  The format in section 7 doesn't have that
benefit and is thus somewhat more fragile.

As a result, I am presently voting to abstain on this version of this
document.  That means the document may still proceed to publication
unless several of my peers on the IESG choose to also abstain.  In short,
I feel strongly enough about this to not help this document progress,
but not so strongly that I'm going to actively oppose progression.

Changing the text to say that RFC 3156 SHOULD be used instead
of the format in section 7 for environments that support MIME
multipart messages would cause me to positively support forward
progression of this document.

Also be aware that a large number of the normative references probably
count as downrefs.  If there are any downref sticklers left on the IESG,
it may save time to IETF last call the downrefs in advance if that wasn't
already done.

Section 6 mentions the constant '0x864CFB' while the sample code uses the constant '0x1864cfb'; which one is correct?

Other nits:
Section 3.7.1.3
Could use int32_t (ISO C 99 standard) rather than nonstandard Int32.
Section 4.2.3
I was confused about packet length vs. body length especially after
reading the last paragraph.  Perhaps make sure you've used the terms
consistently.
Section 7.1
What happens if the "- " prefix causes the line to exceed SMTP line
length limits (998 characters)?

[Ballot comment]
RFC 3156 SHOULD be used for clear signatures instead of the format in
section 7 for environments that support MIME multipart messages.  The
format in section 7 adds ugly clutter that is visible to non-PGP users
while multipart/security provides a mechanism independent way to
suppress display of signature crud and part boundaries.  Furthermore,
multipart/security is the standard way to tell gateways which muck with
whitespace or encodings to keep their hands off.  The format in section 7
does not have that benefit either.  I'll change my vote from abstain to
no objection if this is fixed.

Also be aware that a large number of the normative references probably
count as downrefs.  If there are any downref sticklers left on the IESG,
it may save time to IETF last call the downrefs in advance if that wasn't
already done.

Section 6 mentions the constant '0x864CFB' while the sample code uses the constant '0x1864cfb'; which one is correct?

Other nits:
Section 3.7.1.3
Could use int32_t (ISO C 99 standard) rather than nonstandard Int32.
Section 4.2.3
I was confused about packet length vs. body length especially after
reading the last paragraph.  Perhaps make sure you've used the terms
consistently.
Section 7.1
What happens if the "- " prefix causes the line to exceed SMTP line
length limits (998 characters)?

[Ballot comment]
RFC 3156 SHOULD be used for clear signatures instead of the format in section 7 for environments that support MIME multipart messages.  The format in section 7 adds ugly clutter that is visible to non-PGP users while multipart/security provides a mechanism independent way to suppress display of signature crud and part boundaries.  Furthermore, multipart/security is the standard way to tell gateways which muck with whitespace or encodings to keep their hands off.  The format in section 7 does not have that benefit either.  I'll change my vote from abstain to no objection if this is fixed.

Also be aware that a large number of the normative references probably count as downrefs.  If there are any downref sticklers left on the IESG, it may save time to IETF last call the downrefs in advance if that wasn't already done.

Section 6 mentions the constant '0x864CFB' while the sample code uses the constant '0x1864cfb'; which one is correct?

Other nits:
Section 3.7.1.3
Could use int32_t (ISO C 99 standard) rather than nonstandard Int32.
Section 4.2.3
I was confused about packet length vs. body length especially after
reading the last paragraph.  Perhaps make sure you've used the terms
consistently.
Section 7.1
What happens if the "- " prefix causes the line to exceed SMTP line
length limits (998 characters)?

IANA Additional Comments:

IANA received comments from David Shaw.

> Action #3: * Editors are requested to provide information
> on the status of Tag 15 & 16 in this sub-registry.
> * IANA should place this as the first sub-registry
> in the PGP registry.
> * It is not clear what the maximum value in this
> registry is.

The maximum value in this registry is 63 (the field that stores this
value in OpenPGP is 6 bits long). I believe tags 15 and 16 should be
available for assignment. They were used at one point in an earlier
draft, but are not currently allocated for anything.

> Action #6 : * Note: XXXX needs to be filled in by editors
> as either avaiable or name and reference to
> specification
> * The document said nothing about the range
> 111-255 so I guessed what author wanted.

I believe you can list the XXXX items as available for assignment.
They're not currently allocated for anything. Note also that the
maximum value in this registry is 127 (it's a 7-bit field).

> Action #7 : IESG: needs to appoint the expert

What is the method for this? Is it reasonable to list the authors of
the draft as experts or does it need to be a single person? (Hal
Finney or Jon Callas?)

> Action #10 : value 0x03 was changed to 0x04 as 0x03 is
> not a unique bit and value 0x04 was not used.

I think this may be a misunderstanding. I believe 0x03 is actually
correct as this field is not a collection of bits, but rather a list
of values.

Jon, it occurs to me that we didn't do the traditional "100-110 for
private use" for this. Perhaps we should.

> Action #12 : Initial content where supposed to be in
> section 5, it has no content other than
> subsections. Where are the initial contents ?

The packet types already discussed have version fields as part of the
packet. Section 10.2.3 is noting that changing a packet version is
effectively the same as making a new packet type (both being IETF
CONSENSUS). The current version number for each packet type are given
in the discussion of that packet (in section 5).

> Action #13 : * Please let IANA know if any of the
> values listed above as available for
> assignment are not available ie. reserved
> or allocated.
> Also provide references for 2, 3, 18,19,
> 20, 21 if any
> * The document said nothing about the
> range 111-255 so I guessed what editor wanted.

2 and 3 are deprecated, and are marked as SHOULD NOT generate. Do
they still need a reference? If so, then it should probably be [HAC].

18, 19, and 21 have no references because they are not fully
specified. Those numbers are just reserved for future use.

20 used to be defined in an earlier draft, but is not defined any
longer. There are no references as 20 effectively doesn't exist.

IANA Last call Comments:

*** IANA has questions ***

* Since there are 16 actions. I would like authors,
  chairs, and ADs to confirm all the actions below
  are all correct.  Also in each action, IANA put
    notes for our assumption/understanding.  However,
  just to be clear, I put all notes up front.


Action #1 :  this is the high level action that creates
          the holding registry that contains all the
          sub registries.  (assumption)

Action #3: * Editors are requested to provide information
            on the status of Tag 15 & 16 in this sub-registry.
          * IANA should place this as the first sub-registry
            in the PGP registry.
          * It is not clear what the maximum value in this
            registry is.

Action #4 :  The document said nothing about the range
          111-255 so IANA guessed what authors wanted.

Action #5 :  The document said nothing about the range
          111-255 so IANA guessed what authors wanted.

Action #6 : * Note: XXXX needs to be filled in by editors
          as either avaiable or name and reference to
          specification
            * The document said nothing about the range
          111-255 so I guessed what author wanted.

Action #7 : IESG: needs to appoint the expert

Action #10 : value 0x03 was changed to 0x04 as 0x03 is
          not a unique bit and value 0x04 was not used.

Action #12 : Initial content where supposed to be in
          section 5, it has no content other than
          subsections. Where are the initial contents ?

Action #13 : * Please let IANA know if any of the
          values listed above as available for
          assignment are not available ie. reserved
          or allocated.
          Also provide references for 2, 3, 18,19,
          20, 21 if any
              * The document said nothing about the
          range 111-255 so I guessed what editor wanted.

Action #14 :  The document said nothing about the range
          111-255 so I guessed what editor wanted.

Action #15 : The document said nothing about the range
          111-255 so I guessed what editor wanted.

Action #16 : The document said nothing about the range
          111-255 so I guessed what editor wanted.

Also : sections 10.4, 10.5, 10.6 contain NO instructions
for IANA but contain guidelines for future registrations
and process for protocol developers. These sections do
not belong in the IANA considerations section per sae

IANA needs some guidance on order of subregistries this
documents are asking for.

-----

Action #1: (Section 10 )
Upon approval of this document, the IANA will create
the following registry "PGP" located at

http://www.iana.org/assignments/TBD-pgp
Initial contents of this registry will be:
Allocation policy: IETF Consensus

Initial Contents:


Note: this is the high level action that creates
the holding registry that contains all the sub
registries from below.

------------------------------------

Action #2: (Section 10.1)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "PGP String-to-Key (S2K)"
Allocation policy: IETF consensus
Initial contents of this sub-registry will be:


ID S2K Type
-- --- ----
0 Simple S2K [RFC-openpgp-rfc2440bis-19]
1 Salted S2K [RFC-openpgp-rfc2440bis-19]
2 Reserved value [RFC-openpgp-rfc2440bis-19]
3 Iterated and Salted S2K [RFC-openpgp-rfc2440bis-19]
4-99 Availabe for Assignment [RFC-openpgp-rfc2440bis-19]
100 to 110 Private/Experimental S2K [RFC-openpgp-rfc2440bis-19]

------------------------------------

Acation #3: (Section 10.2 and 4.3)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "PGP Packet Types/Tags"
Allocation policy: IETF consensus
Initial contents of this sub-registry will be:
value
0 Reserved - a packet tag MUST NOT have this value [RFC-2440bis-19]
1 Public-Key Encrypted Session Key Packet [RFC-2440bis-19]
2 Signature Packet [RFC-2440bis-19]
3 Symmetric-Key Encrypted Session Key Packet [RFC-2440bis-19]
4 One-Pass Signature Packet [RFC-2440bis-19]
5 Secret Key Packet [RFC-2440bis-19]
6 Public Key Packet [RFC-2440bis-19]
7 Secret Subkey Packet [RFC-2440bis-19]
8 Compressed Data Packet [RFC-2440bis-19]
9 Symmetrically Encrypted Data Packet [RFC-2440bis-19]
10 Marker Packet [RFC-2440bis-19]
11 Literal Data Packet [RFC-2440bis-19]
12 Trust Packet [RFC-2440bis-19]
13 User ID Packet [RFC-2440bis-19]
14 Public Subkey Packet [RFC-2440bis-19]
15-16 Unkown ???? [XXX]
17 User Attribute Packet [RFC-2440bis-19]
18 Sym. Encrypted and Integrity Protected Data Packet [RFC-2440bis-
19]
19 Modification Detection Code Packet [RFC-2440bis-19]
20-59 Available for assginment [RFC-2440bis-19]
60-63 Private or Experimental Values [RFC-2440bis-19]
64-??? Available for assginment [RFC-2440bis-19]

Note: Editors are requested to provide information on
the status of Tag 15 & 16 in this sub-registry.
Note: IANA should place this as the first sub-registry
in the PGP registry.

Note: It is not clear what the maximum value in this
registry is.

------------------------------------

Action #4: (Section 10.2.1 and 5.12)
Upon approval of this document, the IANA will in the
following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "PGP User Attribute Types"
Allocation policy: IETF consensus
Initial contents of this sub-registry will be:

value Attribute Reference
0 Reserved [RFC-2440bis-19]
1 image [RFC-2440bis-19]
2-99 Available for assignement [RFC-2440bis-19]
100-110 Experimental or private use [RFC-2440bis-19]
111-255 Available for assignment [RFC-2440bis-19]

Note: The document said nothing about the range
111-255 so I guessed what they wanted.


------------------------------------

Action #5: (Section 10.2.1.1 and 5.12.1)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Image Format Subpacket Types"
Allocation policy: IETF consensus

Initial contents of this sub-registry will be:
value Attribute Reference
0 Reserved [RFC-2440bis-19]
1 JPEG [RFC-2440bis-19]
2-99 Available for assignement [RFC-2440bis-19]
100-110 Experimental or private use [RFC-2440bis-19]
111-255 Available for assignment [RFC-2440bis-19]

Note: The document said nothing about the range
111-255 so I guessed what they wanted.
------------------------------------

Action #6: (Section 10.2.2 and 5.12.1)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Signature Subpacket types"
Initial contents of this sub-registry will be:

value Attribute
0 XXXXX
1 XXXXX
2 signature creation time [RFC-2440bis-19]
3 signature expiration time [RFC-2440bis-19]
4 exportable certification [RFC-2440bis-19]
5 trust signature [RFC-2440bis-19]
6 regular expression [RFC-2440bis-19]
7 revocable [RFC-2440bis-19]
8 XXXXXX
9 key expiration time [RFC-2440bis-19]
10 placeholder for backward compatibility  [RFC-2440bis-19]
11 preferred symmetric algorithms [RFC-2440bis-19]
12 revocation key [RFC-2440bis-19]
13-15 XXXXX
16 issuer key ID [RFC-2440bis-19]
17-19 XXXXX
20 notation data [RFC-2440bis-19]
21 preferred hash algorithms [RFC-2440bis-19]
22 preferred compression algorithms [RFC-2440bis-19]
23 key server preferences [RFC-2440bis-19]
24 preferred key server [RFC-2440bis-19]
25 primary User ID [RFC-2440bis-19]
26 policy URI [RFC-2440bis-19]
27 key flags [RFC-2440bis-19]
28 signer's User ID [RFC-2440bis-19]
29 reason for revocation [RFC-2440bis-19]
30 features [RFC-2440bis-19]
31 signature target [RFC-2440bis-19]
32 embedded signature [RFC-2440bis-19]
100-110 private or experimental [RFC-2440bis-19]
111-255 Available for assignment [RFC-2440bis-19]

Allocation policy: IETF consensus
Note: The document said nothing about the range
111-255 so I guessed what they wanted.

Note: XXXX needs to be filled in by editors as
either avaiable or name and reference to specification
Note: The document said nothing about the range
111-255 so I guessed what they wanted.

------------------------------------

Action #7: (Section 10.2.2.1 and 5.2.3.16)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Signature Notation Data
Subpacket types" Initial contents of this sub-registry
will be: 


Rules:
OpenPGP signatures further contain a mechanism for
extensions in signatures. These are the Notation
Data subpackets, which contain a key/value pair.
Notations contain a user space which is completely
unmanaged and an IETF space.

This specification creates a registry of Signature
Notation Data types. The registry includes the
Signature Notation Data type, the name of the
Signature Notation Data, its allowed values, and a
reference to the defining specification. The
initial values for this registry can be found in
5.2.3.16. Adding a new Signature Notation
Data subpacket MUST be done through the EXPERT
REVIEW method, as described in [RFC2434].

Notation names are arbitrary strings encoded in
UTF-8. They reside two name spaces: The IETF name
space and the user name space.

The IETF name space is registered with IANA. These
names MUST NOT contain the "@" character (0x40).
This this is a tag for the user name space.

IESG: needs to appoint the expert

------------------------------------

Action #8: (Section 10.2.2.2 and 5.2.3.17)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Key Server Preference Extensions"
Initial contents of this sub-registry will be:

This is a variable length bit field
first octet
0x80 No-modify [RFC-2440bis-19]
other bits Available for assignemt [RFC-2440bis-19]

Allocation Policy: IETF Consensus


------------------------------------

Action #9: (Section 10.2.2.3 and 5.2.3.21)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Key Flags Extensions"

Allocation Policy: IETF Consensus.

Initial contents of this sub-registry will be:

First Octet:
0x01 - This key may be used to certify other keys.  [RFC-2440bis-19]

0x02 - This key may be used to sign data.  [RFC-2440bis-19]

0x04 - This key may be used to encrypt communications. [RFC-2440bis-19]

0x08 - This key may be used to encrypt storage. [RFC-2440bis-19]

0x10 - The private component of this key may have been split [RFC-2440bis-
19]
by a secret-sharing mechanism.

0x20 - This key may be used for authentication. [RFC-2440bis-19]

0x40 - Available for assignment [RFC-2440bis-19]

0x80 - The private component of this key may be
in the [RFC-2440bis-19] possession of more than
one person.



------------------------------------

Action #10: (Section 10.2.2.4 and 5.2.3.23)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Reasons for Revocation
Extensions [RFC-2440bis-19]"
Allocation policy: IETF Consensus.

Initial Contents:
One octet flag
0x00 - No reason specified (key revocations or cert revocations) [RFC-
2440bis-19]
0x01 - Key is superseded (key revocations) [RFC-2440bis-19]
0x02 - Key material has been compromised (key revocations) [RFC-2440bis-
19]
0x04 - Key is retired and no longer used (key revocations) [RFC-2440bis-
19]
0x20 - User ID information is no longer valid (cert revocations) [RFC-
2440bis-19]
0x40 - Available for assignment [RFC-2440bis-19]
0x80 - Available for assignment [RFC-2440bis-19]


Note : value 0x03 was changed to 0x04 as 0x03 is not a unique bit
and value 0x04 was not used.
------------------------------------


Action #11: (Section 10.2.2.5 and 5.2.3.24)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Reasons for Revocation
Extensions [RFC-2440bis-19]"

Allocation policy: IETF Consensus.

Initial Contents:

First octet:
0x01 - Modification Detection (packets 18 and 19) [RFC-2440bis-19]
0x02 - 0x80 available for assignemnt [RFC-2440bis-19]


------------------------------------

Action #12: (Section 10.2.3 and 5)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "New Packet Versions [RFC-2440bis-19]"
Allocation policy: IETF Consensus.

NOTE: Initial content where supposed to be in
section 5, it has no content other than subsections.
Where are the initial contents ?

------------------------------------


Action #13: (Section 10.3.1 and 9.1)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Public Key Algorithms [RFC-2440bis-19]"
Allocation policy: IETF Consensus.

Initial Contents:
ID Algorithm
-- ---------
0 Reserved
1 RSA (Encrypt or Sign) [HAC]
2 RSA Encrypt-Only
3 RSA Sign-Only
4-15 Available for assignment [RFC-2440bis-19]
16 Elgamal (Encrypt-Only), see [ELGAMAL] [HAC]
17 DSA (Digital Signature Algorithm) [FIPS186] [HAC]
18 Reserved for Elliptic Curve
19 Reserved for ECDSA
20 Reserved (formerly Elgamal Encrypt or Sign)
21 Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME)
22-99 Available for Assignment
100 to 110 Private/Experimental algorithm.
111-255 Available for Assignment

Note: Please let IANA know if any of the values
listed above as available for assignment are not
available ie. reserved or allocated.

Also provide references for 2, 3, 18,19, 20, 21 if any

Note: The document said nothing about the range
111-255 so I guessed what they wanted.

References:
[HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.


[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).

FIPS 186-3 describes keys greater than 1024 bits.
The latest draft is at:


[ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a
Signature Scheme Based on Discrete Logarithms,"
IEEE Transactions on Information Theory, v. IT-31,
n. 4, 1985, pp. 469-472.

------------------------------------


Action #14: (Section 10.3.2 and 9.2)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Symetric Key Algorithms [RFC-2440bis-19]"
Allocation policy: IETF Consensus.

Initial Contents:
ID Algorithm
-- ---------
0 Plaintext or unencrypted data [RFC-2440bis-19]
1 IDEA [IDEA]
2 TripleDES (DES-EDE, [SCHNEIER] [HAC]
168 bit key derived from 192)
3 CAST5 (128 bit key, as per RFC 2144)
4 Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 Reserved
6 Reserved
7 AES with 128-bit key [AES]
8 AES with 192-bit key [AES]
9 AES with 256-bit key [AES]
10 Twofish with 256-bit key [TWOFISH]
11-99 Available for assignment [RFC-2440bis-19]
100-110 Private/Experimental algorithm. [RFC-2440bis-19]
111-255 Available for assignment [RFC-2440bis-19]

Note: The document said nothing about the range
111-255 so I guessed what they wanted.


References:
[AES] Advanced Encryption Standards Questions and Answers



[BLOWFISH] Schneier, B. "Description of a New
Variable-Length Key, 64-Bit Block Cipher (Blowfish)"
Fast Software Encryption, Cambridge Security Workshop
Proceedings (December 1993), Springer-Verlag, 1994,
pp191-204



[HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.


[IDEA] Lai, X, "On the design and security of block
ciphers", ETH Series in Information Processing,
J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag
Knostanz, Technische Hochschule (Zurich), 1992

[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999.

------------------------------------

Action #15: (Section 10.3.3 and 9.4)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Hash Algorithms [RFC-2440bis-19]"
Allocation policy: IETF Consensus.

Initial Contents:
ID Algorithm Text Name Reference
-- --------- ---- ---- ---- ----
1 - MD5 "MD5" [RFC1321]
2 - SHA-1 "SHA1" [FIPS180]
3 - RIPE-MD/160 "RIPEMD160" [REF-XXX]
4-7 - Reserved [RFC-2440bis-19]
8 - SHA256 "SHA256" [FIPS180]
9 - SHA384 "SHA384" [FIPS180]
10 - SHA512 "SHA512" [FIPS180]
11 - SHA224 "SHA224" [FIPS180]
4-99 - Available for assignment [RFC-2440bis-19]
100 to 110 - Private/Experimental algorithm.
111-255 - Available for assignment [RFC-2440bis-19]

Note: The document said nothing about the range
111-255 so I guessed what they wanted.

------------------------------------

Action #16: (Section 10.3.4 and 9.3)
Upon approval of this document, the IANA will in
the following registry "PGP " located at

http://www.iana.org/assignments/TBD-pgp

create a sub-registry "Compression Algorithms [RFC-2440bis-19]"
Allocation policy: IETF Consensus.

Initial Contents:
ID Algorithm
-- ---------
0 - Uncompressed [RFC-2440bis-19]
1 - ZIP [RFC 1951]
2 - ZLIB [RFC 1950]
3 - BZip2 [BZ2]
4-99 - Available for assignment [RFC-2440bis-19]
100-110 - Private/Experimental algorithm.[RFC-2440bis-19]
111-255 - Available for assignment [RFC-2440bis-19]


Note: The document said nothing about the range
111-255 so I guessed what they wanted.

References:
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page"

------------------------------------



Note: sections 10.4, 10.5, 10.6 contain NO
instructions for IANA but contain guidelines for
future registrations and process for protocol
developers. These sections do not belong in the
IANA considerations section per sae

We understand the above to be the only IANA
Action for this document.