Martin Rex пишет:
What I don't understand is whether the deprecation applies to
GOST R34.10-1994 in general,
Yes.
or only to GOST R34.10-1994 as a
signature algorithm.
No.
I am somewhat illiterate to crypto math, so I'm wondering whether
it is technicall possible to use a GOST
This new charter looks great otherwise, but I did have a reaction on this:
- IKEv2 supports mutual authentication with a shared secret, but this
mechanism is intended for strong shared secrets. User-chosen
passwords are typically of low entropy and subject to off-line
dictionary attacks when
No hat.
On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote:
Martin Rex пишет:
I am somewhat illiterate to crypto math, so I'm wondering whether
it is technicall possible to use a GOST R34.10-1994 key agreement
(ephemeral keys) in conjunction with GOST R34.10-2001
Andrew Sullivan wrote:
On Tue, Feb 16, 2010 at 01:18:48PM +0300, Basil Dolmatov wrote:
Martin Rex пиÑеÑ:
I am somewhat illiterate to crypto math, so I'm wondering whether
it is technicall possible to use a GOST R34.10-1994 key agreement
(ephemeral keys) in conjunction with
I've been working with JaNet(UK) on providing a federation solution for
client applications such as mail readers, filesystem clients,
XMPP clients and the like. There are fairly good solutions such as Open
ID, Information Card and SAML for web applications. Within an
enterprise, you have
On Sun, Feb 14, 2010 at 4:54 AM, SM s...@resistor.net wrote:
Hello,
At 02:55 12-02-10, IAB Chair wrote:
IAB statement on the RPKI.
= RPKI as a prerequisite for improving the security of the global
routing system.
It would be preposterous of me to disagree with the opinion of the learned
There are two separate functions in the routing layer. There are
security issues in both cases.
The first function is to map IP address ranges to AS numbers. This is
a global mapping, if an IP address range maps to an AS number in
France the same mapping will be good in Brazil.
The second
All,
hHere are at least 2 issues under discussion within this thread.
I'd like to address them separately, but in the same note.
(1) Quality of GOST specification
While I'm very happy to see any algorithm publicly documented
in an I-D or RFC, I agree with Martin Rex that the current
RFC-4357 on
Perhaps it would help elucidate matters if we knew the precise criteria
In particular, is the requirement to support Gost or is it that all
the algs used be approved
If the second case 1) what would be the root zone criteria and 2)
would these regulation issues disappear if the root zone
One point that seems to be ambiguous here is what the role of an rfc
is with respect to defacto standards status
In theory informational rfc do not establish or modify standards. In
practice the broken process that stops anything being a standard and
makes those we do have obsolete means
PEM (Five years and counting before the project faded away without a
definitive declaration of failure)
DNSEC (Ten years and counting)
They have yet to succeed in setting up a single PKI.
Signing the root of the DNSSEC scheme will not change anything, I
asked for details of the proposed
PKI is all politics. A PKI is a political infrastructure.
Saying that politics and business rules are out of scope when you
propose a PKI design is basically saying that you aren't going to look
at any of the issues that are relevant to the design.
Sandra Murphy is right when she says that
It is now generally accepted that PEM was undeployable because the
single root model is not workable. Nobody was going to trust IANA as
the ultimate root of trust, nor were they going to trust RSA.
ICANN has accepted responsibility for the DNS infrastructure.
Unfortunately they don't seem to
No, you think that you have a unitary root.
Actually you have separation of powers. ICANN is not currently in sole
control. There is a marked difference between the ICANN view of its
authority and the RIRs and national TLDs
Removing the ambiguity means a very large change in the ability of
ICANN
On 15/02/2010 7:43 PM, Olafur Gudmundsson wrote:
On 15/02/2010 6:37 PM, Martin Rex wrote:
Mark Andrews wrote:
In message201002151420.o1fekcmx024...@fs4113.wdf.sap.corp, Martin
Rex writes
:
OK, I'm sorry. For the DNSsec GOST signature I-D, the
default/prefered (?)
parameter sets are
Alfred,
I didn't forget about these. Responses inline.
spt
Alfred � wrote:
I have taken a closer look at draft-ietf-smime-cms-rsa-kem-10
and will send another detailed editorial review to the authors.
Below are my more significant comments and questions:
(A)
Shouldn't this memo be updated
Phillip Hallam-Baker wrote:
It is now generally accepted that PEM was undeployable because the
single root model is not workable. Nobody was going to trust IANA as
the ultimate root of trust, nor were they going to trust RSA.
ICANN has accepted responsibility for the DNS infrastructure.
On 16.02.10 4:21, Phillip Hallam-Baker wrote:
deploy as at present does not seem to have occurred to them. It is
quite possible that what is driving the GOST issue is that the GRU
really has a thing about vanity crypto. But I think it much more
likely that they are going to use it as part of a
Dmitry Burkov wrote:
On 16.02.10 4:21, Phillip Hallam-Baker wrote:
deploy as at present does not seem to have occurred to them. It is
quite possible that what is driving the GOST issue is that the GRU
really has a thing about vanity crypto. But I think it much more
likely that they are
A new IRTF research group on virtual networks has been created. Charter
included below.
--aaron
IRTF Chair
---
Virtual Networks Research Group (VNRG)
Chairs
Joe Touch to...@isi.edu mailto:to...@isi.edu
Martin Stiemerling
I'd suggest asking it on the URI mailing list, see here:
http://lists.w3.org/Archives/Public/uri/
for archives and pointers to how to join. I also suspect that
you may be interested in Larry Masinter's dated uri proposals.
See http://tools.ietf.org/html/draft-masinter-dated-uri-06 .
My own
Alfred,
Thanks for your response. A few additional thoughts inline:
(1)
EAP is asymmetric, and so far EAP support in IKEv2 only serves to
authenticate the IKE initiator to the IKE responder.
The IKE responder (most likly actually a server or a security
gateway protecting the server) still
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Document:
[Oops, resending with the updated address for Laura Liess. Sorry for the repeat]
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from
Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
(Apparently, the subject lines have been messed up entirely
on this list these days. I tried to return to the actual
subject, GOST signatures for DNSSEC.)
I fear you are in danger of drawing the wrong conclusions based
on incomplete information.
This is an update of my review of draft-ietf-ccamp-pc-spc-rsvpte-ext-06, based
on the newly released version 07.
Updated Summary: Ready for publication. (I said draft standard the first
time-but this is intended as a proposed standard, right?)
Major Issues: None
Minor Issues: None
Dmitry Burkov wrote:
As you know we have some national regulation in crypto.
To implement DNSSEC we should
or to use GOST (at this moment) and to comply regulations
or to ignore DNSSEC (no comments)
or try to change national laws (also no comments).
If someone can give us an advice - what
The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'Transport Protocol Port Randomization Recommendations '
draft-ietf-tsvwg-port-randomization-06.txt as a BCP
The IESG plans to make a decision in the next few weeks, and
The IESG has approved the following document:
- 'Clearance Sponsor Attribute '
draft-turner-clearancesponsor-attribute-03.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Tim Polk.
A URL of
The IESG has approved the following document:
- 'Elliptic Curve Private Key Structure '
draft-turner-ecprivatekey-04.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Tim Polk.
A URL of this
The IESG has approved the following document:
- 'Device Owner Attribute '
draft-turner-deviceowner-attribute-03.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Tim Polk.
A URL of this
31 matches
Mail list logo
