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

Re: [Debconf-discuss] OpenPGP primary key expirations



On Monday, August 16, 2010, Daniel Kahn Gillmor wrote:
> On 08/13/2010 07:25 PM, Milan Kupcevic wrote:
> > Chris Knadle wrote:
> >> If you look at the signatures of my key [0x6A9FDD74], I think
> >> you'll see something interesting which will also likely answer
> >> your question.
> > 
> > Hm, the signature in question is valid exactly 5 years after the
> > signing date.
> 
> yup, i'm currently making most of my certifications with a 5-year
> expiration date.  This is a compromise between the commonly-used
> X.509 model (1-year certifications, regular renewals and hassles)
> and the commonly-used OpenPGP model (no expiration, no real
> infrastructure to ensure that a key remains under control of the
> certified party).

I would have liked to have discussed these and other further details 
at the GPG Keymanagement BoF -- but there wasn't time.  Perhaps 
someone will take notes on these and other issues and at least mention 
them as things to discuss before the next keysigning.

...
> I'm not convinced that my current approach is a great one, and i'd
> be happy to discuss it with people who feel strongly one way or
> the other (maybe gnupg-users@gnupg.org would be a better forum
> than debconf-discuss, though).

I'd rather not change mailing lists [at least not for the overall 
discussion] -- while it sounds like it makes sense, I find that in 
practice changing mailing lists ruins the context.  In this case we're 
discussing what is/was "correct" for a keysigning /for DebConf10/, or 
"keysinging for Debian", and going to that mailing list will 
automatically change the context to be "keysinging in general".  I 
will sign up for the gnupg-users list anyway, though, so I'm still 
glad you pointed it out.

As for your approach, I honestly don't know what to say -- I can't say 
it's wrong, I can't say it's correct, and I don't have any particular 
issue with it.  I do agree that 1 year would be too short, so at 
minimum I agree with your compromise.

I did follow the instructions for the keysigning for DebConf10 for 
making a key revocation, printed two copies, and took one copy off-
site.  That was the suggestion for making sure that the key owner 
could revoke the key in case control over the key was lost.  As such I 
also cannot say that signing my key without an expiration would be 
incorrect, either.  [And I was surprised at how short the revocation 
signature was -- about 14 lines of gobbly-gook for a 4096 bit key.]




Another aspect that is troublesome are PhotoIDs in keys; several 
people had them.  In order to go view the PhotoIDs I opened Kleopatra 
in KDE4 (4.4.5 in Sid), and when viewing a key it says this:

   "At the moment, Kleopatra does not support photos in certificates.
    It has no support for adding, nor for displaying them.  This is
    for the following reasons:

    - Photos give a false sense of security.
    - Photos increase the size of certificates."

I don't agree with the latter reason, as I think this should be a 
personal choice and I don't think PhotoIDs are "wrong", and I'm 
annoyed that such a choice is being made for me by the author of the 
tool rather than simply giving a warning.  However as I couldn't find 
a way of displaying the PhotoIDs to verify them, I also couldn't sign 
them.  :-/

I'd appreciate other people's opinions on PhotoIDs, as I don't have 
any strong feelings about them one way or the other.

> I suspect that we need better infrastructure, including tools which
> alert the user when some of their own certifications are due to
> expire.

I completely agree.  This is a good topic for [gnupg-users].

> If those alerts provided an easy way to do sensible things
> (e.g. follow up in a standard manner with the keyholder, or
> directly re-issue the cert if the user knows it to still be good),
> even better.

That would be good.  However, let me ask this: how would you be able 
to remotely verify that the user is still in control over the key?  
That's the one snag I see.



I'm also having trouble when attempting to use an exported secret 
subkey for signing use on a laptop.  I would like to think that using 
'--export-secret-subkey' for the signing subkey and importing it on 
the laptop would be the correct procedure.  I've been trying to find 
some instructions on how to set this up properly, and have not found a 
good source yet.  Anybody got one?

   -- Chris

Attachment: signature.asc
Description: Digital signature


Reply to: