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 documented in draft-shaw-openpgp-hkp-00.  This seems
like another detail worth including in any update.  looking in
dbserver.ml, i don't see any corresponding offset= query parameter.  so
if X-HKP-Results-Count == limit + 2, if an HKP client wants to get the
last two that were beyond the limit, they have to re-fetch the whole
list of keys.  Is that right?


I'm thinking here of the protocol from the perspective of an HKP client;
i don't think a client should need to know the gory details of how any
particular HKP server is implemented in order to be able to interact
with it robustly.  While we may decide that there are certain error
cases that are common enough (or dangerous enough) to call them out
specifically in the protocol spec, it seems simplest to start by
specifying a general error code that we expect to be interpreted as
"Server broken, please try again later or try someone else" (perhaps
this is HTTP's "500 Internal Server Error").  It would also be useful to
provide guidance for how we expect a responsible HKP client to respond
to that error state.

For those of us who run sks or other keyservers behind reverse proxies,
there may also be system errors that come into play at the proxy level.
 So having an explicit understanding of what sorts of errors HKP clients
expect to see and how they should handle them would help to inform best
practices for reverse proxy configuration.

It might turn out that these answers are all very simple.  that's great!
 in that case, let's document them explicitly, and then we can set about
testing the various HKP clients and reverse proxies to ensure that they
behave reasonably in the face of the expected range of responses.

Regards,

--dkg

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

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 "unlimited".
+> Handle limit=0 so that can ask for number of results without getting results.
+>
+> From email submission:
+> Back when X-HKP-Results-Count: was discussed, David Shaw suggested that
+> limit=0 should return no results, but include the header, to let a
+> client poll for how many results exist, without retrieving any.  See:
+>   http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00015.html
+>
+> Please find attached a patch. Plus a couple of related cleanups in HTTP error
+> response handling.

+ 1.1.2:
+  - Johan van Selst's patch implementing Phil Pennock's suggestion
+       of an X-HKP-Results-Count: header to returned web server queries
+   - Johan van Selst's patch to add Content-length header to web results

+> changeset:   49:68f88ae59b6a
+> user:        John Clizbe <John.Clizbe< at >gmail.com>
+> date:        Thu Nov 04 02:37:31 2010 -0500
+> files:       dbserver.ml request.ml wserver.ml
+> description:
+> Johan van Selst's patch implementing Phil Pennock's suggestion
+> of an X-KHP-Results-Count: header to returned web server queries
+>
+> http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00016.html
+>
+> changeset:   48:e6d918ac4c66
+> user:        John Clizbe <John.Clizbe< at >gmail.com>
+> date:        Wed Nov 03 21:58:51 2010 -0500
+> files:       wserver.ml
+> description:
+> Johan van Selst's patch to add Content-length header to web results
+>
+> http://lists.nongnu.org/archive/html/sks-devel/2010-11/msg00005.html


Could you /maybe just possibly/ tie this down to something like a real error
condition instead of something so ambiguous?  Taking a look at lines 245-307
of wserver.ml may be helpful.

- -John

PS: Dan, please DO NOT CC me on replies to the list.

- -- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( < at > ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys< at >gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"




- -- 
John P. Clizbe                   Inet:   JPClizbe(a)comcast DOT nyet
Golden Bear Networks             PGP/GPG KeyID: 0x608D2A10
"Be who you are and say what you feel because those who mind don't matter
and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the £33 ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with SeaMonkey - http://www.enigmail.net/

iF4EAREIAAYFAlGJzkoACgkQ614Z89ZWmCU5YgD/ePoiYfnYBStLptdHxLnF5CUc
z/Kuq0R8pZpgNuGPVXcA+wW5gNXtO+YAJqkG2z2C9lx+nC3YWNWVCHXNeXmNMIv4
=y7Pw
-----END PGP SIGNATURE-----
_______________________________________________
openpgp mailing list
openpgp< at >ietf.org
https://www.ietf.org/mailman/listinfo/openpgp

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) should include
test vectors (example data) for all packet and subpacket types discussed
in the standard to remove ambiguity.

Daniel

On 05/04/2013 08:50 PM, Peter Todd wrote:


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

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 timestamps to OpenPGP signatures as
Signature Notation Data. In short the timestamp would apply to the
digest of the data being signed proving that it existed before some
particular time; the timestamp would act to prove the Signature Creation
Time field was correct, at least in one direction.(1) Timestamps on data
is one obvious applications. Timestamping PGP keys is another, although
actually doing so usefully is tricky.


Lets look at data first. Signature Notation Data can either be signed or
unsigned. A timestamp should be stand-alone - its validity must depend
on the notary rather than the user - so there really isn't any need to
actually sign the timestamp itself other than to say the user intended
for it to be there.

Another factor favoring unsigned timestamps is that with hashing-based
timestamps they often can be extended after the fact. For instance, in
GuardTime's implementation a timestamp is first submitted to a 'level'
with a 1 second interval, quickly returning the timestamp. However its
only later that the merkle tree is timestamped permanently by inclusion
into a widely-witness newspaper ad. An unsigned timestamp allows you to
extend your timestamp after the fact to include all the intermediary
digests required to link it to that permanent, trustworthy record.
Similarly timestamps from different notaries may be collected at a later
time.

However, timestamping signatures themselves can also be useful. If a key
is compromised after some known date, a timestamp of a signature before
that date can still be trusted.


As for timestamping PGP keys in theory it can help determine
trustworthyness by making the assumption that the earlier key is the one
that is valid. (in addition to WOT and other evaluations) However, it is
not as simple as just timestamping the fingerprint of the primary key,
because an attacker can always re-use an existing key, and create new
User ID packets and sign them; you need to sign the User ID packets as
well. Unfortunately this isn't a very easy to understand user
experience, and evaluating exactly what is being proven is subtle.


Regardless all this does suggest that one timestamp packet be used for
the whole signature allowing for multiple elements to be incorporated
into one merkle tree within that packet to be timestamped in one go,
saving space. In this case I think it would make most sense to either
define a new packet type, or simply use a signature packet missing the
actual signature. The latter doesn't really seem ideal though, for
instance it would require a redundent signature creation time.


Anyway, I'd appreciate some comments on my line of thought, in
particular what people think of trade-offs between the simplicity of one
timestamp per signature, and trying to have some sort of common
timestamp packet containing a DAG of hash operations for all timestamped
data, as well as the usefulness of integrating timestamping into OpenPGP
signatures in general.


1) Potentially random beacons such as the Bitcon blockchain or the under
development NIST beacon could be used to prove a signature was created
after a given time, but a random beacon can only prove the signature,
not the data being signed.

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,
which is expected on received messages.


Well I know,.. but now we give them even reason.




Well of course I can always do whatever I want... but isn't the whole
idea of a standard that everyone should follow it as far as possible?
Clearly I can put a semicolon separated list of address, jabber
account, date of birth, name and email address into the UID,... but
everyone will think I'm crazy.


Well but X.509 simply sucks for it's trust model ;-)


And there's a similar syntax for the other signature subpacktes? The
dates? The policy sig subpacket? Key usage? etc.?


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

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.org=42' ....

makes foo a critical notation.


Shalom-Salam,

   Werner

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 properties, which is the important part here.


Absolutely agreed... especially in a machine understandable way.

That could be done via policy sig subpackets... even though this is
not exactly defined right now.


In principle yes... it’s handy though to have a unique identifier
(which is not the fingerprint) on keys... whether this needs to be
signed by other users or just by the key itself is another question.


+1

Absolutely agreed, though it would be even better to allow arbitrary
number of such.
Maybe one could even think of doing the same with differen crypto
systems (i.e. one that was not vulnerable to Shore ;) )

+1

Not so sure about this... to me the rationale behind the detached sigs
is rather that you can keep the signed-only file in clean text.
The encrpyted file is unreadable anyway, so you can also include the
session key in it... and that you can re-encrypt quite fast at a later
point for different users.




On Mon, Apr 29, 2013 at 7:17 AM, Robert J. Hansen <rjh< at >sixdemonbag.org> wrote:
Well that's kinda stupid as it boils down to the hen egg problem, ain't it?
Especially that OpenPGP looses ground in most areas (unless perhaps
OpenSource) against X.509 should already show, that there are many
showstoppers.



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

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 operator key" are 
too involved in the business layer to be foisted onto anyone else.  The 
history of key-bits being used for human claims suggests this is a fast 
way to failure.  E.g., non-revocation and the infamous 
you-must-understand-me bit.

I don't know if this logic applies to anyone else.  But if it did, 
hypothetically, I might record your claims in my key uids as such:



uid                  Iang [HTTP-auth] (social-networks) <iang< at >iang.org>
uid                  Systemics [UDC-agent] (Black-2012) <iang< at >iang.org>





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

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://www.ietf.org/mailman/listinfo/openpgp

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 
any reviews) and we were invited to submit the final paper and a 
payment of $500+ fee to present the paper. We decided to use the 
fee for better purposes than making Prof. Hamid Arabnia (Chairman 
of WORLDCOMP) rich. After that, we received few reminders from 
WORLDCOMP to pay the fee but we never responded. 


We MUST say that you should look at the above website if you have any thoughts 
to submit a paper to WORLDCOMP.  DBLP and other indexing agencies have stopped 
indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See 
http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the 
conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of
http://sites.google.com/site/dumpconf for comments from well-known researchers 
about WORLDCOMP. 


The status of your WORLDCOMP papers can be changed from scientific
to other (i.e., junk or non-technical) at any time. Better not to have a paper than 
having it in WORLDCOMP and spoil the resume and peace of mind forever!


Our study revealed that WORLDCOMP is a money making business, 
using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing 
out a small chunk of that money (around 20 dollars per paper published 
in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) 
who publicizes WORLDCOMP and also defends it at various forums, using 
fake/anonymous names. The puppet uses fake names and defames other conferences
to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to 
threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). 
That is, the puppet does all his best to get a maximum number of papers published 
at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. 


Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has 
refused to provide the venue for WORLDCOMP’13 because of the fears of their image 
being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 
is taking place at a different resort. WORLDCOMP will not be held after 2013. 


The draft paper submission deadline is over but still there are no committee 
members, no reviewers, and there is no conference Chairman. The only contact 
details available on WORLDCOMP’s website is just an email address! 

Let us make a direct request to Prof. Hamid arabnia: publish all reviews for 
all the papers (after blocking identifiable details) since 2000 conference. Reveal 
the names and affiliations of all the reviewers (for each year) and how many 
papers each reviewer had reviewed on average. We also request him to look at 
the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 


Sorry for posting to multiple lists. Spreading the word is the only way to stop 
this bogus conference. Please forward this message to other mailing lists and people. 


We are shocked with Prof. Hamid Arabnia and his puppet’s activities 
http://worldcomp-fake-bogus.blogspot.com   Search Google using the 
keyword worldcomp fake for additional links.

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

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 keyserver for primary keys that have Bob's OTR key as a
subkey, there is no way for her to distinguish between Bob's actual key
and Mallory's Fake-Bob key.  A back-sig would provide such a
distinguishing mechanism.

Practically, at least one common implementation (GnuPG) does not create
a back-sig for authentication-capable keys.  Should it do so?  Do other
implementations do so?

Are there any downsides to including a back-sig in every
authentication-capable subkey?

Regards,

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

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. I was merely pointing out that if you put the critical flag on it, then it possibly would have unintended failure modes and meta-failures.

The correct thing to do is a notation. Put the critical flag on it. Please.

Jon

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

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