: Rodney Thayer [EMAIL PROTECTED]
Subject: Re: Crypographically Strong Software Distribution HOWTO
(I can't tell where the signal and where the noise is in this thread,
so I'll just say this to you, feel free to forward.)
PKIX and it's legacy ancestor, X.509, have a 'revocation reason'
field
At 02:13 PM 7/3/2001 -0400, V. Alex Brennen wrote:
In the case of such a large project, perhaps you could issue
a separate role key pair to each developer and generate
revocation certificates which are held by the core group for
those keys. When a developer leaves the group, the revocation
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 3 Jul 2001, Greg Broiles wrote:
At 02:13 PM 7/3/2001 -0400, V. Alex Brennen wrote:
In the case of such a large project, perhaps you could issue
a separate role key pair to each developer and generate
revocation certificates which are
Oh? How? All you are suggesting is that the role key is held by a CA -
well, who is that going to be, then?
Unh, no. The same way the ASF determines who gets commit access could
be teh same way the ASF determines who their CA will give
release-signing keys to. The same way the ASF takes away
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 3 Jul 2001, Ben Laurie wrote:
What this does not address is the common situation where the
distribution gets signed by a different person each time (example:
Apache).
I had hoped the suggestion to identify a release master was
Rich Salz wrote:
Oh? How? All you are suggesting is that the role key is held by a CA -
well, who is that going to be, then?
Unh, no. The same way the ASF determines who gets commit access could
be teh same way the ASF determines who their CA will give
release-signing keys to. The
What this does not address is the common situation where the
distribution gets signed by a different person each time (example:
Apache). I've put some pretty serious thought into this problem and come
to a few conclusions.
The obvious answer is use a role key.
All that work... when a
V. Alex Brennen wrote:
In the case of such a large project, perhaps you could issue
a separate role key pair to each developer and generate
revocation certificates which are held by the core group for
those keys. When a developer leaves the group, the revocation
certificate for his key would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 3 Jul 2001, Ben Laurie wrote:
I think it would be good to see the Apache Project make a
policy as to request (require) the signature of releases
by the individual responsible for the release. It would
also be good to ask apache core
On Tue, 3 Jul 2001, Rich Salz wrote:
So how does this work in practice?
Who controls commit access? What mechanisms protect that? The same
mechanisms that protect *the source* can be the same mechanisms that
protect *the release.*
I believe we have a greater need for protecting the
On Mon, Jul 02, 2001 at 04:37:00PM -0400, Rich Salz wrote:
I've written a HOWTO on the cryptographically strong distribution
of computer software. Any constructive criticism would be
appreciated.
Seems pretty nice; thanks for doing this.
Any chance of using SHA1 instead of MD5? MD5
In our last episode (Re: Crypographically Strong Software Distribution
HOWTO, shown on 7/2/01), Kent Crispin said:
Any references for either the weaknesses of md5, or what the IETF has to
say on the issue?
Hans Dobbertin found some weaknesses in MD5 in 1996. I found two quickie
references
On Mon, 2 Jul 2001, Jon Callas wrote:
The answer is that you SHOULD (in IETF terms, see RFC 2119,
http://www.ietf.org/rfc/rfc2119.txt for a definition of MAY, SHOULD,
MUST, etc.)
That document clarifies nothing, it might as well say the following -
1. MUST This word, or the terms REQUIRED
Jon Callas wrote:
Hans Dobbertin found some weaknesses in MD5 in 1996. I found two quickie
references, a note by Dobbertin on the issue:
http://www.math.ohio-state.edu/~fiedorow/PGP/MD5_discussion
and his paper on the weaknesses:
http://www.cs.ucsd.edu/users/bsy/dobbertin.ps
The
I've written a HOWTO on the cryptographically strong distribution
of computer software. Any constructive criticism would be
appreciated. I hope to standardize the use of this model in
the GNU/Linux free software community.
You can find the HOWTO here:
Hans Dobbertin found some weaknesses in MD5 in 1996.
Also note that RFC 2104 on the HMAC construction used in IPSEC
explicitly cites Dobbertin and says the attack does not apply:
this is because dobbertin's attack works only
against message-digest applications of md5;
his attack doesn't work
16 matches
Mail list logo
