[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft Update

David Shaw wrote:
> On Mon, Jul 28, 2008 at 09:56:11AM -0700, Jon Callas wrote:
>> 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.
> 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.

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,