gmane.ietf.openpgp

Re: keyserver protocol

John Clizbe — 2013-05-08T12:25:07

Casey Marshall is well along in his implementation, Hockeypuck, which if I
understood correctly, is implementing HKP with the behavior of SKS. He is
implementing the reconciliation process of SKS as well. He has implemented
them in Go.


Yes, it's a HTTP header, returned since 1.1.2. See this thread for more
details about why it exists: [Sks-devel] SKS, Content-Length and HEAD requests
[https://lists.nongnu.org/archive/html/sks-devel/2010-11/threads.html#00000 ]

This may be getting a bit SKS-centric for the OpenPGP list.

Re: keyserver protocol

Daniel Kahn Gillmor — 2013-05-08T04:32:36

Thanks for these details, John.  This is exactly the sort of thing that
i wanted to start getting fleshed out.

On 05/08/2013 12:02 AM, John Clizbe wrote:

well, this is how they're implemented in SKS, which is the defacto
reference implementation, for sure.  so yes, documenting this in the
only public spec of the HKP protocol would be good.


This header (i think you're implying that it is an HTTP response header)
doesn't seem to be used at all in GnuPG if i'm searching
git://git.gnupg.org/gnupg.git properly.

I know there are other HKP client implementations but (like sks on the
server side) gnupg is a sort of defacto reference implementation.  If
it's not making use of this header, then it probably needs to be better
documented and patches pushed to gpg.

What should a responsible client do or assume if this header is absent
from an HKP response?

How should a responsible client respond if X-HKP-Results-Count is
greater than the limit query parameter?  for that matter, limit itself
doesn't seem to be docu

Re: keyserver protocol

John Clizbe — 2013-05-08T04:02:25

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Daniel Kahn Gillmor wrote:

You /must/ mean documenting how those two are already implemented?

X-HKP-Results-Count: number of matching keys
Content-Length: number of bytes in resulting keys

- From the SKS CHANGELOG(+) and Mercurial commit log(+>):

+ 1.1.4
+   - Fix X-HKP-Results-Count so that limit=0 returns no results, but include
+     the header, to let client poll for how many results exist, without
+     retrieving any. Submitted by Phil Pennock. See:
+     http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00015.html

+> changeset:   115:47835fd59b63
+> parent:      113:73ba20267254
+> user:        Phil Pennock <codehack< at >spodhuis.org>
+> date:        Sat Apr 21 18:24:46 2012 -0500
+> files:       dbserver.ml key.ml request.ml wserver.ml
+> description:
+> Limit fix for limit=0
+> Return real status text strings, rather than confusing "500 OK".
+> Handle No_results as an exception type, giving 404 instead of 500.
+> Treat limit of -1 (or <0) as

Re: keyserver protocol

Daniel A. Nagy — 2013-05-07T15:44:40

Also, I think that it makes sense to explicitly allow for partial
implementations of the protocol. For example, one that only allows for
searching by keyID's or even just long keyID's and fingerprints. I
think, there should be a clear way to communicate that the use of an
unsupported part of the protocol has been attempted.

Bests,

Daniel

_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

Re: keyserver protocol

Daniel Kahn Gillmor — 2013-05-07T15:11:45


David, i would like to see this picked back up if possible.  Is there a
way that i can help?

In particular, I would like to see the error signalling and semantics be
more clearly and explicitly defined, so that (for example) when a
keyserver has a problem the user agents (e.g. client tools like gpg
--refresh) have a clear way to distinguish between cases like:

 0) "I have no key material matching this name/keyid at all"

 1) "I have too many keys that match this search to bother you with an
     insanely long list"

 2) "something is broken in my database, and I'm confused"

and so forth.

Any thoughts on what would be reasonable next steps?

Regards

    --dkg
_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

Re: Timestamping

Daniel A. Nagy — 2013-05-05T20:44:30

Speaking of timestamps.

There is this feature in OpenPGP (RFC4880, section 5.2.1) called a
standalone signature that is calculated only on its own packet data. It
is, as I understand, useful for including (or referencing by hash) in
newer documents thereby proving (evidencing) that they are NEWER than
the standalone sig, provided that the maker of these standalone sigs can
be trusted to put correct timestamps into them. By contrast, timestamp
sigs prove (well, evidence) that the document is OLDER than the sig.

Question:

Is there any OpenPGP implementation that creates and correctly
interprets such signatures?

I am asking, because GnuPG 1.4.11 seems not to handle them the way I
think it should. I created a script that creates signatures on an empty
binary document, which verify fine with gpg, but if I change the
signature type to standalone sig, gpg complains. This might be a gpg
issue, but I would like to see a working reference implementation.

In general, I think the new standard (or a separate RFC) sh

Re: Timestamping

Peter Todd — 2013-05-04T18:50:57

I think I've read that paper before actually, or perhaps the EFF's
version, but yes, CA transparency schemes are interesting to me and I
think they too could benefit from timestamping as an additional source
of auditing.

Bitcoin in particular I find interesting because it's the first
trustworthy *decentralized* timestamping scheme to be created. Its
timestamps aren't particularly accurate - Bitcoin has a rule where every
node accepts blocks with a timestamp less than 2 hours ahead of what it
believes the time is - but they can be used in conjunction with other
centralized timestamping schemes to give the guarantee that if the
timestamp was faked, it was at least done so in the past!

Obviously the same guarantee is useful for CA auditing, but I'm probably
getting off-topic here...

Re: Timestamping

Ben Laurie — 2013-05-03T19:06:43

You might be interested in Certificate Transparency:
http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf

On 3 May 2013 18:40, Peter Todd <pete< at >petertodd.org> wrote:
_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

Timestamping

Peter Todd — 2013-05-03T17:40:15

I've been working on and off on a open-source timestamping package
called OpenTimestamps (https://github.com/opentimestamps)

It's based on hashing, usually by combining many digests into a merkle
tree, with the tip digest being timestamped by some method. To date it's
been used with the Bitcoin blockchain as the timestamping method, but
the architecture is notary agnostic - RFC3161 support is on my TODO list
for instance.

The actual structure of a timestamp consists of a set of operations,
generally hash algorithms, forming a DAG. The operations are computed,
and provided the path from the input digest to the notarized
timestamp(s) is valid one can prove that the data existed before the
time. Nothing very exciting really in terms of actual crypto, but as far
as I know my project is the first to attempt a flexible, general
solution based on hashing that can, in principle, support a variety of
notary methods.


Timestamping came up on the GnuPG mailing list, and Werner Koch
suggested I look into adding times

Re: OpenPGPv5 wish list

Philippe Cerfon — 2013-04-29T23:08:44

Well I think what has been proposed here now all belongs to the lowest
layer, it’s just cleaning up that one and making it more general.
Especially the proposals by Hauke seem to be just what the key
management system should be responsible for and which OpenPGP
currently cannot really fulful. Like that I have several subkeys where
one is explicitly marked as "not so safe" because I use it e.g. on my
Android phone... and where clients have a machine readable way to warn
me about data signed by such keys.

Also my proposals for having more (standardised) descriptive fileds
(name, address, IM, colour of eyes, employee) seems to be quite
crucial to me.
Right now people put such distinguising information often as comment
into their UID, but that kinda sucks (and it kinda violates the email
RFCs, which tell that any client interpreting mail addresses must
ignore the comments).

Or I'd like to be able to also include IM addresses in the keys, so
that such clients could use this information to select the right key

Re: OpenPGPv5 wish list

Werner Koch — 2013-04-29T18:40:17

On Mon, 29 Apr 2013 19:53, philcerf< at >gmail.com said:


Depends on what you call advanced.  OpenPGP is a low-level protocol and
never really tried to address the application layer. 


Why should a government do that?  eID cards started in Europe (iirc, the
German electronic signature law was the first at all).  Europe has a
history of waiting for X, aehmm the OSI network stack, and thus it is
quite obvious that they started with X.400 et al.  Further, you can make
more (consulting) money with weakly defined/complex protocols than with
a clean solution.  The latter almost never wins (cf. IPSec lessons).


Maybe not for your application, so go and use your own thing for it.
There is nothing which will stop you.  What about putting a DN into it?


Because X.509 has all the useless bells and whistles which have been
suggested in the past as the solution to every problem.  Well alright,
OpenPGP provides very similar ways to implement such features but
fortunately it has not yet been abused


  gpg -N '!foo< at >example.

Re: OpenPGPv5 wish list

Philippe Cerfon — 2013-04-29T17:53:40

Moving over to openpgp< at >ietf.org from gnupg-devel.


On Mon, Apr 29, 2013 at 1:52 PM, Werner Koch <wk< at >gnupg.org> wrote:
Well actually the contrary seems to be the case... OpenPGP is rather
only used for mail and plain file encryption/signing, which covers of
course already many fields, but nothing advanced.
It would never have any chance to be used for government ID cards, or
similar projects.

...
Yeah I knew... but right now it's also used for the name of the user,
which is the primary identification property... and it shouldn't be
used for that (from a design POV).


Obviously I don't want X.509 or I'd use it.
And I don't see how this is touched by X.509 anyway.
Of course there showed never problems up with the critical flag,
simply as no-one uses it... yeah I know, gpg understands it... but one
cannot even set it, can one?




On Mon, Apr 29, 2013 at 4:37 AM, Hauke Laging
<mailinglisten< at >hauke-laging.de> wrote:
Well technically,... but there need such common notification to be
defined, for all these proper

Re: OpenPGPv5 wish list

ianG — 2013-04-29T09:40:14



Some comments from my experience/perspective, only.  In my work I have 
done this by using pgp's comment field aka uid.  Here's some:

$ gpg -k | grep uid

uid                  Iang [certification] (Africa-2012) <iang< at >iang.org>
uid                  Iang [contract] (lowsec-PIZZA-only) <iang< at >iang.org>
uid                  Systemics [operator] (Africa-2012) <iang< at >iang.org>
uid                  Systemics [server] (Babba-2012) <iang< at >iang.org>
uid                  Systemics [receipt] (Babba-2012) <iang< at >iang.org>
uid                  Systemics [receipt] (offa-20130101) <iang< at >iang.org>
uid                  Systemics [server] (offa-20130102) <iang< at >iang.org>


In my software I use the [tag] for the purpose, the (text) as a human 
comment, and everything else as the name of the keyholder.  You could do 
whatever tho.

Perhaps more on point, I do not want the OpenPGP system to provide me 
with bits that allow me to set purpose or anything else, because OpenPGP 
is too low-level.  My designed claims like "this is an o

Re: OpenPGPv5 wish list

Jean-Jacques — 2013-04-29T09:15:32

Le Mon, 29 Apr 2013 01:17:04 -0400,
"Robert J. Hansen" <rjh< at >sixdemonbag.org> a écrit :


Yep, so I switched the thread to the other mailing list.

So I answered because I really "need" such feature in OpenPGP for
real-world :

2) What is the key used for?

And I see at least 4 purposes :
 - To authenticate itself through TLS  [RFC6091]
 - Maybe To sign other certificates (subkeys on smartcard issues)
 - To authenticate through HTTP (gpgauth or
   https://github.com/Open-UDC/open-udc/blob/master/docs/HTTP_OpenPGP_Authentication.draft.txt)
 - To sign an OpenUDC transaction.

I work especially on the 2 last purposes. And having the possibility
for the owner to set descriptions, or more flags on its (sub)keys inside
its OpenPGP certificate, would be a more elegant solution than some
workaround we have to manage.

We have to better organize A wish list, or it will be a mess to
identify their elements. :-)

---
jbar.
_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://ww

Biggest Fake Conference in Computer Science

2013-04-27T17:33:05

Biggest Fake Conference in Computer Science


We are researchers from different parts of the world and conducted a study on  
the world’s biggest bogus computer science conference WORLDCOMP 
( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia 
from University of Georgia, USA.


We submitted a fake paper to WORLDCOMP 2011 and again (the same paper 
with a modified title) to WORLDCOMP 2012. This paper had numerous 
fundamental mistakes. Sample statements from that paper include: 

(1). Binary logic is fuzzy logic and vice versa
(2). Pascal developed fuzzy logic
(3). Object oriented languages do not exhibit any polymorphism or inheritance
(4). TCP and IP are synonyms and are part of OSI model 
(5). Distributed systems deal with only one computer
(6). Laptop is an example for a super computer
(7). Operating system is an example for computer hardware


Also, our paper did not express any conceptual meaning.  However, it 
was accepted both the times without any modifications (and without

primary key binding signatures (0x19) for non-signingsubkeys

Daniel Kahn Gillmor — 2013-03-12T21:07:01

hi OpenPGP folks--

I'm wondering whether authentication-capable subkeys should require
primary key binding signatures (aka "back-sigs" or
"cross-certifications").  There seems to be consensus that
signing-capable subkeys need back-sigs, but it's not clear whether
authentication-capable subkeys need the same thing.

RFC 4880 says:


Many (all?) authentication schemes that use public keys involve making a
signature of some data during the authentication exchange.

This suggests to me that authentication-capable subkeys should have a
back-sig.

Also, i'm considering the possibility of OTR-OpenPGP linkage i mentioned
in a previous thread.  It occurs to me that if Alice manages to
authenticate Bob using some OTR handshake, and she wants to bootstrap
her way from that mutual authentication into an OpenPGP authentication,
then a back-sig is critical.

Mallory can already make her own OpenPGP primary key, attach Bob's User
ID to it, and then attach Bob's actual OTR key as a subkey.  If Alice
just scans the keyserve

Re: marking subkeys as constrained for specific use --new key usage flags?

Jon Callas — 2013-03-07T18:59:20


No, because either you want *that* to be critical, too, which has the same criticality issue, or criticality is not important in which case the notation works too.

My comment was one about criticality in general. We have criticality because there were people in the late '90s who thought it was a good idea. It *is* a good idea, but it is such a subtle idea that it's Shannon information, kolmogorov complexity, etc. is more than one bit.


Well, if you did that, you wouldn't not be RFC 4880 compliant. There is a way to do this within the standard -- the notation.

The whole reason that we have notations is so that if you want to do something on your own, there's a supported way to do that. What's wrong with using the supported way, as opposed to violating the standard with hacks? (I'm not above violating standards with hacks, but I expect to have to answer that question, myself.)

If my cynical beliefs about criticality scared you away from doing the right thing, then I apologize. I never intended to do that

Re: marking subkeys as constrained for specific use -- new key usage flags?

Daniel Kahn Gillmor — 2013-03-07T13:45:03

well, yes, this was my original concern.

i wrote:

We already have systems in place (e.g. monkeysphere) that permit the use
of authentication-capable subkeys for ssh systems.  so if i was to mark
my OTR key as authentication-capable, and critical notations were not
widely respected, that wouldn't turn out very well.


If criticality is fraught with problems, doesn't that suggest extending
the usage flags is a more responsible way to go?

or should i create a subkey with all usage flags set to 0, and then
include a notation to indicate the use?  that way, the subkey wouldn't
be used by any existing system except the ones willing to parse and
interpret the notation, regardless of its criticality.

--dkg

_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

Re: Offline key flag

David Shaw — 2013-03-06T00:26:37


Ah, that's a good point.  It's still up to the sender which key to use, but you can choose to give a hint.


Yes.  I've wondered about the split key bit in the past.  The group key bit seems fairly straightforward: if the bit it set, then the verifier of a signature is effectively being told the sender isn't a person, but a group, so the verifier can't expect that a single person was responsible (and similar logic for encryption).  Of course, there is nothing forcing the owners of a group key to set the bit, but if they want to, it's there.

David

_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

Re: Offline key flag

Werner Koch — 2013-03-05T16:53:51

On Tue,  5 Mar 2013 17:30, dshaw< at >jabberwocky.com said:


I have two encryption keys but only one marked as offline.  If someone
wants to send a quick message he would encrypt to the non-offline key.
If he has to tell me something really secret, he would select the
offline key, assuming that I will move the message to a non-networked
box where the offline key is stored.

I am not sure whether this is really useful for most users, but split
and group keys are also somewhat esoteric and not even defined in
OpenPGP.


Salam-Shalom,

   Werner

Offline key flag (was Re: marking subkeys as constrainedfor specific use -- new key usage flags?)

David Shaw — 2013-03-05T16:30:54


Can you give an example why would someone want to publish that their private key is offline?  I'm not sure I see a use for that.

David

_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp