On Jan 19, 2012, at 4:45 PM, Stephen Kent wrote:

> At 3:07 PM -0500 1/19/12, Eric Osterweil wrote:
> 

<snip>

> 
>> OOC, were you all imagining that the CMC authentication for these BGPsec 
>> routers would use a shared secret or a pre-installed certified key o each 
>> remote router?  Also, do you happen to know which nation states require key 
>> escrow these days?
> 
> 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?  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)?

> 
> 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?

I'm sure someone is about to remind me that this is not a PKIX list, but I just 
want to make sure that I understand how we are proposing to use this protocol. 
:)

> 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.

Eric
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr

Reply via email to