Subject: Re: [TLS] OpenPGP and TLS cert_type code point reuse
From: Paul Hoffman <[email-masked]>
To: Sean Turner <[email-masked]>, [email-masked], [email-masked]
Date: Thu, 30 Sep 2010 08:18:30 -0700
List-Id: <ietf-openpgp.imc.org>

At 9:11 AM -0400 9/30/10, Sean Turner wrote:
>draft-mavrogiannopoulos-rfc5081bis reuses the Certificate Type value assigned in RFC 5081 (it's 1).  The extension defined in draft-mavrogiannopoulos-rfc5081bis is not backwards compatible with RFC 5081.  If there were many implementations, then I'd be concerned about reusing the value.  The authors (and I) don't think there are any implementations other than GnuTLS, but I'd like to know if anybody knows of TLS implementations that support RFC 5081.

Given that there is a known implementation of 5081, and given that GnuTLS is reasonably well-deployed, why doesn't draft-mavrogiannopoulos-rfc5081bis simply use a new certificate type number? So far, only 2 out of >200 have been allocated, so there is no shortage.

--Paul Hoffman, Director
--VPN Consortium

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: ECC in OpenPGP
Cc: [email-masked]
Date: Sun, 05 Sep 2010 01:50:10 +1200
Sender: [email-masked]

Simon Josefsson <[email-masked]> writes:

>Supporting PKCS#1 v2.0 padding sounds like a separate effort though.  Is
>anyone interested in that?

I think you need to phrase the question slightly differently:

  Supporting a mechanism that's supported by nothing and that breaks
  compatibility with all existing implementations, and that has no obvious
  advantages over the existing mechanism, sounds like a separate effort
  though.  Is anyone interested in that?

Then the answer becomes self-evident.

Peter.

Date: Fri, 03 Sep 2010 15:04:24 -0700
From: Andrey Jivsov <[email-masked]>
To: Simon Josefsson <[email-masked]>
CC: OpenPGP Working Group <[email-masked]>
Subject: Re: ECC in OpenPGP
Sender: [email-masked]

  On 09/03/2010 01:55 PM, Simon Josefsson wrote:
> Andrey Jivsov<[email-masked]>  writes:
>
>> NIST is working on SP 800 131, in which RSA 2048 is the minimum
>> allowed algorithm, corresponding to 110 bit security. The document
>> suggests to disallow PKCS#1.5 padding after 2013. If we are going to
>> address this, it makes sense to do such a significant change together
>> along with ECC, as specified in
>> http://sites.google.com/site/brainhub/pgp.
> Supporting PKCS#1 v2.0 padding sounds like a separate effort though.  Is
> anyone interested in that?
>
> /Simon

It's separate, but here is how it is related to ECDH. Using PKCS#1 2.0 
OAEP with default SHA-1 MGF means that the minimum padded field for AES 
256 is 54 bytes.

According to http://tools.ietf.org/html/draft-jivsov-openpgp-ecc-05, 
which is on the above link, it is possible to pack AES 256 key into 48 
bytes using NIST preferred algorithm, which is AES WRAP. This 15% 
overhead is per each recipient of the message. You get higher overhead 
if MGF is not SHA-1 for compliance reasons.

RSA/DH keys don't have this "issue". The only question to resolve then 
is that OAEP contains a hash function. It would be worthwhile to wait 
for SHA3 selection.

From: Simon Josefsson <[email-masked]>
To: Andrey Jivsov <[email-masked]>
Cc: OpenPGP Working Group <[email-masked]>
Subject: Re: ECC in OpenPGP
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Fri, 03 Sep 2010 22:55:31 +0200
Sender: [email-masked]

Andrey Jivsov <[email-masked]> writes:

> NIST is working on SP 800 131, in which RSA 2048 is the minimum
> allowed algorithm, corresponding to 110 bit security. The document
> suggests to disallow PKCS#1.5 padding after 2013. If we are going to
> address this, it makes sense to do such a significant change together
> along with ECC, as specified in
> http://sites.google.com/site/brainhub/pgp.

Supporting PKCS#1 v2.0 padding sounds like a separate effort though.  Is
anyone interested in that?

/Simon

Date: Thu, 02 Sep 2010 14:25:37 -0700
From: Andrey Jivsov <[email-masked]>
CC: OpenPGP Working Group <[email-masked]>
Subject: Re: ECC in OpenPGP
Sender: [email-masked]

  To rephrase what Jon, said, it makes no sense to set AES 256 as first 
preferred cipher in 2048 RSA PGP key preference lists, as is commonly 
done (example: default in gpg2 --gen-key). Also note that mentioned 
2Kbyte field is per recipient in each of encrypted messages. The pref. 
change is a practical method to save CPU time without sacrificing security.

NIST is working on SP 800 131, in which RSA 2048 is the minimum allowed 
algorithm, corresponding to 110 bit security. The document suggests to 
disallow PKCS#1.5 padding after 2013. If we are going to address this, 
it makes sense to do such a significant change together along with ECC, 
as specified in http://sites.google.com/site/brainhub/pgp.

The importance of ECC raises if you believe that future computing 
environment will be more diverse and shift more toward weak mobile 
devices. Whether or not you believe in ascent of quantum computers, why 
not get that number of Q-bits higher anyway.