Subject: Draft Update

From: Duane <[email-masked]>
Date: Sun, 27 Jul 2008 10:13:25 +1000

Ok, I've made some updates, firstly removing specific references to DNS
since this is no longer specifically mean to be for DNS and I've other
changes to remove references to using the user id field, and instead
using user attributes to have the information in a format much more
suitable for computers, this makes more sense to me than a blob of
string doesn't need to be split up and parsed to extract the information.

http://open-pgp.info/wiki/index.php?title=Standardisation_of_OpenPGP_Keys_for_Server_Purposes

Is there anything I've missed or overlooked at all?

-- 

Best regards,
 Duane

---

From: Jon Callas <[email-masked]>
Date: Mon, 28 Jul 2008 09:56:11 -0700

> Is there anything I've missed or overlooked at all?

I don't think it was necessary to get rid of all of the user id uses.  
RFC 4880 and 2440 were carefully explicit. Here's the 4880 language:

5.11.  User ID Packet (Tag 13)

    A User ID packet consists of UTF-8 text that is intended to  
represent
    the name and email address of the key holder.  By convention, it
    includes an RFC 2822 [RFC2822] mail name-addr, but there are no
    restrictions on its content.  The packet length in the header
    specifies the length of the User ID.

Note the words "intended" and "by convention." Also, "... but there  
are no restrictions on its content."

The discussion on this is similar to a discussion as to whether  
someone should put DNS information in a new RR or in a TXT record.  
Yes, it's probably better in some respect to expand the user  
attributes, but there's nothing wrong with just putting the text in  
there, especially since there's all this existing code that can  
display it correctly.

There are plenty of cases where a User ID contains nothing but  
descriptive text ("XYZ Corp Security Alert Signing Key") or non-email  
names like an X.509 Distinguished Name.

I agree with people who say that a User Attribute packet is better in  
a pure sense. However, the downside of that is that new UAs need  
setting/getting/display code. Just dropping the text in a UID packet  
is clunkier, but works everywhere.

Knowing when to use which is merely wisdom.

	Jon

---

From: David Shaw <[email-masked]>
Date: Mon, 28 Jul 2008 13:42:26 -0400

> is clunkier, but works everywhere.

Indeed, but since a key must have at least one "real" UID packet, a UA
can only be additional information on top of that.  That's why I
advise that people doing complex multi field (as in this example) and
non-textual things just make a UA - that way, the required UID can be
displayed by all the existing code so the key isn't quasi-anonymous,
but at the same time the new info doesn't have to create hard to read
UIDs full of quoting characters and the like.

I'm not sure it's easier to pack and unpack multi field data into a
text string (with quoting, etc) than it would be to just define a
structure that you own completely.

David

---

From: Duane <[email-masked]>
Date: Tue, 29 Jul 2008 06:38:52 +1000

> structure that you own completely.

I agree with the practicality side of things that just using the UID
field because it works already, no software changes needed etc, on the
other hand I agree with David's sentiments about trying to stuff complex
multi-field information into a single string.

Because nothing exists already when it comes to server uses we have an
opportunity to do things right and we shouldn't do things the easy way
just because it will be the easiest to implement at this point in time,
that's how X.509 got into a bit of a mess, we should learn from the
mistakes they made rather then making them over again.

Currently the draft I've written doesn't use the User ID field at all
for anything, however if one real UID must exist per key then what
should it be?

I don't think it should be hostnames, simply because there could be more
than one and X.509 has a bit of a mess with that, it could be the person
or organisations name I suppose, since that information should be unique
on a per key basis.

In any case I'm more than open to suggestions on what to do here,
however we have information that PKIX didn't have.

-- 

Best regards,
 Duane

Date: Tue, 29 Jul 2008 06:38:52 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Re: Draft Update
Sender: [email-masked]

> structure that you own completely.

I agree with the practicality side of things that just using the UID
field because it works already, no software changes needed etc, on the
other hand I agree with David's sentiments about trying to stuff complex
multi-field information into a single string.

Because nothing exists already when it comes to server uses we have an
opportunity to do things right and we shouldn't do things the easy way
just because it will be the easiest to implement at this point in time,
that's how X.509 got into a bit of a mess, we should learn from the
mistakes they made rather then making them over again.

Currently the draft I've written doesn't use the User ID field at all
for anything, however if one real UID must exist per key then what
should it be?

I don't think it should be hostnames, simply because there could be more
than one and X.509 has a bit of a mess with that, it could be the person
or organisations name I suppose, since that information should be unique
on a per key basis.

In any case I'm more than open to suggestions on what to do here,
however we have information that PKIX didn't have.

-- 

Best regards,
 Duane

Date: Mon, 28 Jul 2008 13:42:26 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Draft Update
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

David

Cc: [email-masked]
From: Jon Callas <[email-masked]>
To: Duane <[email-masked]>
Subject: Re: Draft Update
Date: Mon, 28 Jul 2008 09:56:11 -0700
Sender: [email-masked]

On Jul 26, 2008, at 5:13 PM, Duane wrote:

>
>
> Ok, I've made some updates, firstly removing specific references to =20
> DNS
> string doesn't need to be split up and parsed to extract the =20
> information.
>
> http://open-pgp.info/wiki/index.php?title=3DStandardisation_of_OpenPGP_Ke=
ys_for_Server_Purposes
> Is there anything I've missed or overlooked at all?

I don't think it was necessary to get rid of all of the user id uses. =20
RFC 4880 and 2440 were carefully explicit. Here's the 4880 language:

    A User ID packet consists of UTF-8 text that is intended to =20
represent

Note the words "intended" and "by convention." Also, "... but there =20
are no restrictions on its content."

The discussion on this is similar to a discussion as to whether =20
someone should put DNS information in a new RR or in a TXT record. =20
Yes, it's probably better in some respect to expand the user =20
attributes, but there's nothing wrong with just putting the text in =20
there, especially since there's all this existing code that can =20
display it correctly.

There are plenty of cases where a User ID contains nothing but =20
descriptive text ("XYZ Corp Security Alert Signing Key") or non-email =20
names like an X.509 Distinguished Name.

I agree with people who say that a User Attribute packet is better in =20
a pure sense. However, the downside of that is that new UAs need =20
setting/getting/display code. Just dropping the text in a UID packet =20
is clunkier, but works everywhere.

	Jon

Date: Sat, 26 Jul 2008 21:37:01 -0300
From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Organization: GNU/Buanzo
To: Duane <[email-masked]>
CC: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
OpenPGP: id=6857704D
Sender: [email-masked]

Duane wrote:
| So would I, that's why I started this topic in the first place ;)

Yeah, sure, I mean, I'm ++1 on your idea :) - Anyway, I really look forward to a nice draft on the
idea! :)

- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net

Date: Sun, 27 Jul 2008 10:13:25 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Draft Update
Sender: [email-masked]

-- 

Best regards,
 Duane

Date: Sun, 27 Jul 2008 08:42:00 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
Sender: [email-masked]

David Shaw wrote:

> I'm not suggesting you define multiple OpenPGP user attribute packets. 
> Just one.  Inside that single blob of bytes, you can break it up however
> you want.  Heck, you can define it as text and use the exact same format
> you were discussing before if you like.

In hindsight it doesn't seem like the best way to do it, I guess I have
just answered my question over night, the additional information can be
grouped by the key they are attached to, and if some other organisation
has other hostnames that should be a separate key, and OpenPGP key dumps
can contain multiple keys so that really solves that unless I've
overlooked something fundamental?

-- 

Best regards,
 Duane

Date: Sun, 27 Jul 2008 08:38:47 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
Sender: [email-masked]

Arturo 'Buanzo' Busleiman wrote:

> I'd like to see some server-usage related options in an openpgp key.

So would I, that's why I started this topic in the first place ;)

-- 

Best regards,
 Duane

Date: Sat, 26 Jul 2008 12:57:24 -0300
From: "Arturo 'Buanzo' Busleiman" <[email-masked]>
Organization: GNU/Buanzo
To: David Shaw <[email-masked]>
CC: OpenPGP <[email-masked]>
Subject: Re: Standardisation of User ID usage for Server Purposes
OpenPGP: id=6857704D
Sender: [email-masked]

David Shaw wrote:
| I'm not suggesting you define multiple OpenPGP user attribute packets.
| Just one.  Inside that single blob of bytes, you can break it up however
| you want.  Heck, you can define it as text and use the exact same format
| you were discussing before if you like.

I'd like to see some server-usage related options in an openpgp key. It'd be very useful for
Enigform / mod_openpgp. ( http://maotest.buanzo.org and http://wiki.buanzo.org for more details).

- --
Arturo "Buanzo" Busleiman
Independent Linux and Security Consultant - SANS - OISSG - OWASP
http://www.buanzo.com.ar/pro/eng.html
Mailing List Archives at http://archiver.mailfighter.net

From: David Shaw <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: Standardisation of User ID usage for Server Purposes
Date: Sat, 26 Jul 2008 10:05:03 -0400
Sender: [email-masked]

On Jul 26, 2008, at 12:25 AM, Duane wrote:

>
> David Shaw wrote:
>
>> No.  You can define anything you like, in any form you like.
>> Basically, think of it as being given a chunk of bytes attached to an
>> OpenPGP key.  You can put anything you want in there, in any format
>> you want, to be parsed however you want.  You completely own the
>> format.  OpenPGP then guarantees that your bytes cannot be tampered
>> with, using the same protection that it uses for regular user ID
>> strings.
>
> I'm stuck at this point. If I specify to use multiple types I'm not  
> sure
> how to easily group the additional information to particular hostnames
> or wildcards.
>
> Would anyone have any suggestions at this point in time?

I'm not suggesting you define multiple OpenPGP user attribute  
packets.  Just one.  Inside that single blob of bytes, you can break  
it up however you want.  Heck, you can define it as text and use the  
exact same format you were discussing before if you like.

David

Date: Sat, 26 Jul 2008 14:25:31 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
Sender: [email-masked]

David Shaw wrote:

> No.  You can define anything you like, in any form you like.
> Basically, think of it as being given a chunk of bytes attached to an
> OpenPGP key.  You can put anything you want in there, in any format
> you want, to be parsed however you want.  You completely own the
> format.  OpenPGP then guarantees that your bytes cannot be tampered
> with, using the same protection that it uses for regular user ID
> strings.

I'm stuck at this point. If I specify to use multiple types I'm not sure
how to easily group the additional information to particular hostnames
or wildcards.

Would anyone have any suggestions at this point in time?

-- 

Best regards,
 Duane

Date: Sat, 26 Jul 2008 09:41:10 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
Sender: [email-masked]

David Shaw wrote:

> OpenPGP is not an email-only protocol.  Inevitably, such a key would
> leak from the "server" realm to the "everything else" realm.

X.509 prevented this by usage extensions in the certificates stating
what it should and shouldn't be allowed to do, and also preventing it
from being used for some purposes.

However I most certainly am not suggesting or implying in any way shape
or form that things go down that path with OpenPGP.

Protecting people from themselves has been detrimental and possibly
limited innovation and thinking on the topic because everyone seems to
think the same way when it comes to implementing X.509.

> No.  You can define anything you like, in any form you like.
> Basically, think of it as being given a chunk of bytes attached to an
> OpenPGP key.  You can put anything you want in there, in any format
> you want, to be parsed however you want.  You completely own the
> format.  OpenPGP then guarantees that your bytes cannot be tampered
> with, using the same protection that it uses for regular user ID
> strings.

This is why I posted to this list, because I didn't know if I was doing
things in the best way or not, and I appreciate pointing out things I
didn't consider.

I'll re-write the draft, if someone hasn't already, to incorporate these
new ideas.

-- 

Best regards,
 Duane

Date: Fri, 25 Jul 2008 11:55:57 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Sat, Jul 26, 2008 at 01:14:02AM +1000, Duane wrote:
> 
> David Shaw wrote:
> 
> > Allow me to suggest that overloading the user ID field in such a
> > drastic manner may not be the best way to go here.  If you make it too
> > machine parsable, then it's not very human readable, and vice versa.
> > The user ID field has been a RFC-(2)822 for more or less forever, and
> > a key (even a key intended for special non-common purposes) that
> > doesn't have such a user ID will cause confusion.
> 
> If used for server purposes I doubt it will cause confusion, and such
> keys should not be used for email.

OpenPGP is not an email-only protocol.  Inevitably, such a key would
leak from the "server" realm to the "everything else" realm.

> > Instead, however, I recommend you define a new User Attribute type.
> > This is a user ID alternative that is part of the OpenPGP spec but is
> > not restricted to text, or indeed, any particular format.  Up til now
> > the only defined user attribute has been "image" (used to attach a
> > picture to a key), but if you define a "TLS" or "server" type, you can
> > have exactly the semantics you desire without interfering with the
> > regular user ID.
> 
> Is there any problem with defining several types, ie town/city,
> state/province, country etc?

No.  You can define anything you like, in any form you like.
Basically, think of it as being given a chunk of bytes attached to an
OpenPGP key.  You can put anything you want in there, in any format
you want, to be parsed however you want.  You completely own the
format.  OpenPGP then guarantees that your bytes cannot be tampered
with, using the same protection that it uses for regular user ID
strings.

David

Date: Sat, 26 Jul 2008 01:14:02 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
Sender: [email-masked]

David Shaw wrote:

> Allow me to suggest that overloading the user ID field in such a
> drastic manner may not be the best way to go here.  If you make it too
> machine parsable, then it's not very human readable, and vice versa.
> The user ID field has been a RFC-(2)822 for more or less forever, and
> a key (even a key intended for special non-common purposes) that
> doesn't have such a user ID will cause confusion.

If used for server purposes I doubt it will cause confusion, and such
keys should not be used for email.

> Instead, however, I recommend you define a new User Attribute type.
> This is a user ID alternative that is part of the OpenPGP spec but is
> not restricted to text, or indeed, any particular format.  Up til now
> the only defined user attribute has been "image" (used to attach a
> picture to a key), but if you define a "TLS" or "server" type, you can
> have exactly the semantics you desire without interfering with the
> regular user ID.

Is there any problem with defining several types, ie town/city,
state/province, country etc?

Of course there would be a definite need for a 'DNS' or hostname type.

This would of course be more computer friendly, and there should be no
reason for any user id at all to be on these keys.

-- 

Best regards,
 Duane

Date: Fri, 25 Jul 2008 10:41:29 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Standardisation of User ID usage for Server Purposes
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Fri, Jul 25, 2008 at 10:17:26PM +1000, Duane wrote:
> 
> 
> While I'm happy to see that TLS usage was extended to include OpenPGP
> usage, and I mean no disrespect at all, but the author did not include
> any details on the structure or formatting of the User ID for server
> purposes other than to include the hostname in a single User ID.
> 
> This no better than X.509 in some respects as it didn't mention anything
> about allowing for multiple hostnames, how wild card hostnames should be
> treated or how miscellaneous information could be presented or used.
> 
> I think it's crucial that if people want to adopt or use OpenPGP in
> place of X.509 that all these things must be addressed and standardised.

Allow me to suggest that overloading the user ID field in such a
drastic manner may not be the best way to go here.  If you make it too
machine parsable, then it's not very human readable, and vice versa.
The user ID field has been a RFC-(2)822 for more or less forever, and
a key (even a key intended for special non-common purposes) that
doesn't have such a user ID will cause confusion.

Instead, however, I recommend you define a new User Attribute type.
This is a user ID alternative that is part of the OpenPGP spec but is
not restricted to text, or indeed, any particular format.  Up til now
the only defined user attribute has been "image" (used to attach a
picture to a key), but if you define a "TLS" or "server" type, you can
have exactly the semantics you desire without interfering with the
regular user ID.

David

Date: Fri, 25 Jul 2008 22:17:26 +1000
From: Duane <[email-masked]>
To: [email-masked]
Subject: Standardisation of User ID usage for Server Purposes
Sender: [email-masked]

While I'm happy to see that TLS usage was extended to include OpenPGP
usage, and I mean no disrespect at all, but the author did not include
any details on the structure or formatting of the User ID for server
purposes other than to include the hostname in a single User ID.

This no better than X.509 in some respects as it didn't mention anything
about allowing for multiple hostnames, how wild card hostnames should be
treated or how miscellaneous information could be presented or used.

I think it's crucial that if people want to adopt or use OpenPGP in
place of X.509 that all these things must be addressed and standardised.

Please forgive my presumptions on this topic a little, I have had a lot
more exposure to X.509 in the past and even running a public CA so I
have a little bit of experience when it comes to the kind of things
people want included in certificates, or at least what they've come to
expect already.

To give you a little bit of background where I'm coming from
specifically here, I am already trying to submit a draft through the
DNSEXT working group to incorporate encryption of DNS servers, not just
authentication and originally I had written up a single draft that
covered both the topic of DNS encryption and using OpenPGP keys for servers.

I have since split this draft into two separate drafts and would love
nothing more then to get some comments, suggestions, feedbacks, anything
on my proposal, or even if I could get it adopted by this working group.

Since splitting my draft it's too rough to be presentable just yet in a
normal internet draft form, however that shouldn't take more than a few
days, until then the rough outline is viewable here:

http://open-pgp.info/wiki/index.php?title=Standardisation_of_Information_in_OpenPGP_User_IDs_for_Server_Purposes

-- 

Best regards,
 Duane

Date: Sun, 06 Jul 2008 23:24:50 -0700
From: Andrey Jivsov <[email-masked]>
To: OpenPGP <[email-masked]>
Subject: Re: New Version Notification for draft-jivsov-openpgp-ecc-01
Sender: [email-masked]

> I will wait until at least July 6 before submitting this as a second
> revisions of the draft to IETF.

As promised, the *-01.txt revision is now available:

IETF I-D Submission Tool wrote:
> A new version of I-D, draft-jivsov-openpgp-ecc-01.txt has been successfuly submitted by Andrey Jivsov and posted to the IETF repository.
> 
> Filename:	 draft-jivsov-openpgp-ecc
> Revision:	 01
> Title:		 ECC in OpenPGP
> Creation_date:	 2008-07-06
> WG ID:		 Independent Submission
> Number_of_pages: 14
> 
> Abstract:
> This document proposes an Elliptic Curve Cryptography extension to
> the OpenPGP public key format and specifies three Elliptic Curves
> that enjoy broad support by other standards, including NIST
> standards.  The document aims to standardize an optimal but narrow
> set of parameters for best interoperability and it does so within
> the framework it defines that can be expanded in the future to
> allow more choices.
> 
> Conventions used in this document
> 
> 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 [RFC2119].
> An application MAY implement this draft; note that any [RFC2119]
> keyword within this draft applies to an OpenPGP application only if
> it chooses to implement this draft.
>                                                                                   
> 
> 
> The IETF Secretariat.

All revisions that we discussed so far in HTML, PDF, and TXT formats are 
available at http://brainhub.googlepages.com/pgp .