At Wed, 7 Oct 2015 09:22:40 -0400, Sean Turner wrote:
>
> On Oct 06, 2015, at 08:30, Sandra Murphy wrote:
>> On Oct 5, 2015, at 4:36 PM, David Mandelberg wrote:
>>>
>>> 4. Add text warning relying parties to detect malicious CAs that
>>> cause too many
> I'd prefer a warning in the security considerations section and a
> recommendation to alert the operator.
please. and put this to bed already.
randy
___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
Speaking as regular ol’ member only.
On Oct 5, 2015, at 4:36 PM, David Mandelberg wrote:
> On 2015-09-16 10:38, Sean Turner wrote:
>> Okay so I think we’re in agreement here that we don’t work on #3 now,
>> but I’m also thinking that we should leave #1 and #2 alone for
On 2015-09-16 10:38, Sean Turner wrote:
Okay so I think we’re in agreement here that we don’t work on #3 now,
but I’m also thinking that we should leave #1 and #2 alone for now.
If we think a SHA-1 hash for the RPKI’s KIs are good enough now, then
it sounds like it's also good enough for BGPsec.
On Aug 11, 2015, at 12:12, Richard Hansen wrote:
> Unfortunately no, with the disclaimer that I haven't really thought
> about it in depth. Because of the challenge of accomplishing topic #3,
> I would like start with the much simpler topic #1. Note that I'm not
> opposed to
>> Unfortunately no, with the disclaimer that I haven't really thought
>> about it in depth. Because of the challenge of accomplishing topic #3,
>> I would like start with the much simpler topic #1. Note that I'm not
>> opposed to tackling #3, but the amount of work involved means that I'd
>>
Richard,
no problem.
anyway, my comments may have been too strongly worded. If we feel that
it's important
for router certs to use a different hash alg, then the router cert
profile can
define which alg to use, as an explicit, profiled deviation from the
RPKI cert
profile. We can also
(I see there’s been some more mail on this thread so hopefully I won’t
contradict myself later :/ )
No fear about harming SHA256 deployment! We’re already using it for the
hash+sigs of the Manifest, ROAs, RPKI-certs (both for RPKI and BGPsec).
On Aug 06, 2015, at 20:33, George Michaelson
Saw you’re earlier msg, but figured I’d just reply to this one.
On Aug 07, 2015, at 12:07, Richard Hansen rhan...@bbn.com wrote:
On 2015-08-07 06:35, Randy Bush wrote:
This change would require certificates to be re-issued (or possibly
keys to be rolled) all the way down from Trust Anchors.
On 2015-08-11 13:09, Sean Turner wrote:
Saw you’re earlier msg, but figured I’d just reply to this one.
On Aug 07, 2015, at 12:07, Richard Hansen rhan...@bbn.com wrote:
On 2015-08-07 06:35, Randy Bush wrote:
This change would require certificates to be re-issued (or possibly
keys to be
Sean,
...
Okay so I want to agree. But, I’m still trying to grok something you sent in
an earlier msg
(https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI) that I
think is related when you said:
RPs would not have to calculate/validate the SKI value; they would only
On 2015-08-11 15:48, Stephen Kent wrote:
Sean,
...
Okay so I want to agree. But, I’m still trying to grok something
you sent in an earlier msg
(https://mailarchive.ietf.org/arch/msg/sidr/9vVsAheeeZMj7GI00nyGBDHBqPI)
that I think is related when you said:
RPs would not have to
Hi Sean,
Specifically on this point:
On Aug 7, 2015, at 12:52 AM, Sean Turner turn...@ieca.com wrote:
I’m all for switching to using a better hash algorithm to avoid collisions,
but why can’t we just do it anytime we want? The SKI/AKI fields are only
ever generated by a CA so the RPs
This change would require certificates to be re-issued (or possibly
keys to be rolled) all the way down from Trust Anchors. When the
parent CA re-issues a certificate for the child CA with a new style
SKI, then the child will have to re-issue its products with a new AKI.
This is not
On 2015-08-07 06:35, Randy Bush wrote:
This change would require certificates to be re-issued (or possibly
keys to be rolled) all the way down from Trust Anchors. When the
parent CA re-issues a certificate for the child CA with a new style
SKI, then the child will have to re-issue its products
On Aug 7, 2015, at 11:35 AM, Randy Bush ra...@psg.com wrote:
This change would require certificates to be re-issued (or possibly
keys to be rolled) all the way down from Trust Anchors. When the
parent CA re-issues a certificate for the child CA with a new style
SKI, then the child will
On May 22, 2015, at 10:55, Richard Hansen rhan...@bbn.com wrote:
Hi all,
A while back Sean Turner raised the idea of switching to SHA-256 for the
Subject Key Identifier while discussing rfc6487bis (see
http://article.gmane.org/gmane.ietf.sidr/6878). I see a couple of
reasons to do this:
Can you give me some indication at what level of operation a SHA1 over the
public key risks colliding? 0.001? 0.1?
I don't want to impede progress if SHA256 is sensible, but I have a feeling
this is a risk almost at the noise floor. Since its per-CA, the CA is
presumed to have to hand a
On 2015-08-06 19:52, Sean Turner wrote:
On May 22, 2015, at 10:55, Richard Hansen rhan...@bbn.com wrote:
Hi all,
A while back Sean Turner raised the idea of switching to SHA-256 for the
Subject Key Identifier while discussing rfc6487bis (see
Richard,
Thanks for thinking (in great depth) about the potential security
implications of
SKI collisions in BGPsec.
In the general case of a PKI, collisions of SKI values are not security
relevant.
The SKI MAY be used in path discovery, but the intent was to limit its
use to
quickly
Hi all,
A while back Sean Turner raised the idea of switching to SHA-256 for the
Subject Key Identifier while discussing rfc6487bis (see
http://article.gmane.org/gmane.ietf.sidr/6878). I see a couple of
reasons to do this:
* If/when additional weaknesses are found in SHA-1, 3rd party
21 matches
Mail list logo