At 10:38 PM -0500 1/19/12, Eric Osterweil wrote:
> This is a local matter, so each ISP can decide what approach they
wish to adopt. I personally prefer installing the cert for the CA.
Yeah, I see. I agree that it should be a local policy decision, but
then how does this avoid my initial concern about relying on crypto
material that has been dispatched through customs (or some other
suspect medium), where key material could be intercepted and
extracted?
The focus of BGPSEC is improving inter-AS routing security. The
operator of any AS may not do a great job of securing the keys
associated with some or all of its routers. Other ASes will not, in
general, be able to evaluate the operational security of an AS.
BGPSEC tries to limit the extent to which an AS can lie about routes
that it propagates. Local (within an AS) security errors or poor
practices do not undermine this security feature.
Also, is it safe to assume that you would need the CA(s) to restrict
access to just your own routers (so that unknown routers/certs
cannot issue KGReqs that result in KGReses)?
A CA issuing certs to routers in an AS must have a way to verify that
a cert request is form a legitimate source. There are various ways
this can be done and, ultimately, this too is a local matter.
> When key escrow has been required, it has usually been mandated
for keys used for encryption, not for integrity or authentication.
Since we're discussing integrity & authentication here, it is not
clear that there are any applicable key escrow regulations.
Sorry if I'm confused, but in the diagrams in 1.2.1 and 1.2.2, don't
the curly braces denote encrypted material? I thought the responses
in the key exchanges where necessarily encrypted in this protocol?
Otherwise, the new private key is sent in the clear. I fully accept
the possibility that I'm confused here, but if the material is
encrypted and needs to be decrypted, would the corresponding keys be
subject to escrow policies?
Typically no, because the use of the key being issued is for signing.
> Also, the IETF general policy has been to ignore any
nation-specific crypto regulations when developing standards.
I see, I guess I had thought we should be worried about the eventual
operational issues that might arise. I didn't know this was taboo,
but shouldn't we find a way to address these concerns in order to
help ensure the design's operational relevance when it's finished?
I'm just bringing this up in the sprit of making this design more
relevant, not because I think there should be some official linkage
to escrow policies or anything.
In general it is appropriate to worry about operational issues. But,
I'd suggest that key escrow is not within scope, based on previous
IETF experience in related areas.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
