On Tue, 2015-03-24 at 01:48 +0000, ianG wrote:
- The use of SHA-1 needs to be replaced.
* designate key persons to design the elements. Stick with what they
choose. Argue it a bit, but if we can't shift them, then go with it.
Isn't that the NIST model which kinda blew up?
Any process should be open, fully transparent and even though it's
likely that there will be a number of key people doing a big deal of
work, those shouldn't be designated and any others be more or less
* Less. Algs, hashes, formats, protocols, bit saving, etc.
Well I guess my opinion on that is clear :)
* More. We need to look up into the stack of apps and see what is
needed. Those apps didn't exist when PGP was designed. We are in a new
world now. No point in designing for command line.
+1, at least as long as we don't prioritise one use case over the other
and we still have many people/fields where the perfectly mutually
authenticated integrity/encryption is desired.
* Vendors. Ain't nothing gonna happen unless you get them on side.
By them, I mean the big ones.
I'd rather consider that problematic.
Typically the main interest of any company is not necessarily the
general good but rather making money.
And we know of far to many cases in the past were companies or other big
players (e.g. standardisation bodies) intentionally weakened crypto
Just take the whole GSM development and weak keys... even though this
was motivated by the government agencies, the vendors all knew what they
were agreeing to.
* project planning. Let's not treat this as a committee, let's set
up some coding projects to actually move the game forward. Like, a C
team, a Java team, PHP, what else? Mandate: to track the draft,
compat, and push for more speed from the designers.
Sounds compelling, especially when looking at the back and forth that
the CFRG saw recently ;)
But not at the expense of flexibility, and the things should be finished
when it's finished - not when the date is due.
Description: S/MIME cryptographic signature
openpgp mailing list