[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PGPticket
On 5/26/98, Men from Black Helicopters forced tzeruch@ceddec.com to write:
> I don't think the PGPsdk does proper V4 sigs for anything other than keys.
> Since the format below is close, but not quite the V4 key spec, I would be
> curious about what you have done or are doing, or if PGP has updated
> something in the past few weeks.
actually I used the 1.5 sdk (part of PGP 6.0) which allows you to do low level
crypto calls. I worked as the PGPsdk developer support guy for while and was able
to use that to write my initial tests. you have to form the packets yoursef.
> My implementation does V4 sigs
> correctly, but it took a long while to figure out why PGP was rejecting my
> signed messages. FYI, my implementation is a freeware library with full
> source and is at www.cryptography.org in the new directory, moved to the
> libraries occasionally. The current version is opgp99m, but I already
> have a patch which should appear later this week. It uses zlib and SSLeay,
> and it targeted at Unix, but it compiles for Visual C, and with patches
> for PalmOS3 (though I haven't tested it).
>
great! this is the other implementation that I was looking for.
>
> If this is based on a V4 signature packet, then here and all following
> seem to be missing the subpacket length count byte(s). This would be 0x05
> just before the 0x82. The following comments also apply to this (and why
> create something that is 95% like a V4 sig packet but different enough as
> to require new routines)?
>
yup.. you are correct! I just check out the spec and found the following
5.2.3.1. Signature Subpacket Specification
The subpacket fields consist of zero or more signature subpackets.
Each set of subpackets is preceded by a two-octet scalar count of
the length of the set of subpackets.
Each subpacket consists of a subpacket header and a body. The
header consists of:
- the subpacket length (1, 2, or 5 octets)
- the subpacket type (1 octet)
- the subpacket specific data
>
> The following byte should be moved further down. There is a "Should"
> stating that the creation time and issuer ID occur first since these are
> non-optional fields, and it allows a quick finding of the keyid (so that
> the public key can be quickly looked up) instead of having to scan every
> field.
fair enough.
>
> Why 2 octets of name length? Also, with the (elided) subpacket length
> byte, the length of the string is known.
>
see 5.2.3.15. Notation Data
(4 octets of flags, 2 octets of name length (M),
2 octets of value length (N),
M octets of name data,
N octets of value data)
> > - Eight-octet key ID
> > - One-octet public key algorithm.
> > - One octet scaler length count for public Key fingerprint
> > - N octets public Key fingerprint data
>
> This is not a good idea. Keyids are not guaranteed to be unique, and are
> actually the LSBs of the fingerprint for V4 keys, so would be redundant
> here. The keyid would have to point to the full public key somewhere
> which would have the public key algorithm.
>
keyid is used for quick lookup of a key only, the FP is used to verify
the key. I would prefer that the fp was used only, and this is an option too.
of course the right thing to do is to transition all openpgp spec refs of keyids
to FPs..
> And why bury this in the signature packet itself? You can do a V3 style
> sig followed by a literal or compressed, or a v4 onepass where a sig is at
> the end.
you lost me here?
> Moreover the (entire) public key could be included which would
> eliminate some of the things here. Though I can see that it would be
> nicer to do everything in a single packet.
this is also a great idea, but there are some cases where a tciket is used
with a large number of subjects and it might be worth saving a few bytes by
not including the keys themselves....
> [protocol deleted]
>
> If the admin doesn't really verify the key, you might get into man-in-the
> middle attacks. I send a key request, FakeServer processes it and submits
> a request to Admin, who processes it and returns it to FakeServer.
> FakeServer creates a counterfeit auth pointing to Fakeserver. Now
> Fakeserver pretends to be the user to the auth, and the auth to the user.
> I haven't looked at this closely, so there may be a check that cannot be
> overcome in the protocol.
agreed, the admin must verify the key before issuing a ticket against it
this is specific to the implementation.. but you are right this is a security
concern..
thanks again for all the feedback, I have enclosed the updated ticket format
below.. I would like to move this discussion to the pgpticket list at
ietf-pgpticket@vmeng.com
Updted pgpticket message format
A PGPticket packet contains:
- Packet Tag
- One-octet version number (4).
- One-octet Standalone signature type (2).
- One-octet public key algorithm.
- One-octet hash algorithm.
- Two-octet scalar octet count for following hashed subpacket data.
Certificate validity Information (first half) consisting of:
- One-octet subpacket length (5)
- One-octet signature creation time subpacket type (82)
- Four-octet time field
Certificate Issuer Information consisting of:
- One-octet subpacket length (9)
- One-octet signature creation issuer key ID type (90)
- Eight-octet key ID
Certificate validity Information (last half) consisting of:
- One-octet subpacket length (5)
- One-octet signature expiration time subpacket type (83)
- Four-octet time field
Certificate Authorization Information consisting of:
- two or five-octet subpacket length (N + 13)
- One-octet Notation Data subpacket type (94)
- 4 octets of flags (0)
- 2 octets of name length (4)
- 2 octets of value length (N),
- 4 octets of name data ('AUTH')
- N octets of authorization string data
Certificate Subject Information consisting of:
- two or five-octet subpacket length (N + 13)
- One-octet Notation Data subpacket type (94)
- 4 octets of flags (0)
- 2 octets of name length (4)
- 2 octets of value length (N),
- 4 octets of name data ('SUBJ')
N octets of Subject string data for each subject
authorized in this certifcate consisting of
- Eight-octet key ID
- One-octet public key algorithm.
- One octet scaler length count for public Key fingerprint
- N octets public Key fingerprint data
Optional Certificate Delegation Information consisting of:
- One-octet subpacket length (13)
- One-octet Notation Data subpacket type (20)
- 4 octets of flags (0)
- 2 octets of name length (4)
- 2 octets of value length (0),
- 4 octets of name data ('DELG')
- Two-octet scalar octet count for following unhashed subpacket
data.
- Unhashed subpacket data. (zero or more subpackets)
- Two-octet field holding left 16 bits of signed hash value.
- One or more multi-precision integers comprising the signature.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vinnie Moscaritolo
Wordwide Developer Technical Support
N&C/Hardware
Apple Computer, Inc. email: vinnie@apple.com
3 Infinite Loop, MS: 303-2T phone: 408.974.5560
Cupertino, CA 95014 fax: 408.862.7602
Fingerprint: 0AAF 9A74 113F 7FDD 97E6 04BD 1D7A 2D86 6F17 2A0A
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~