Tero Kivinen <kivi...@iki.fi> wrote:
>> I am not really following this discussion very well.
>> I'm not sure if this is general advice or ACP specific advince.
> This discussion was not ACP specific, this was just generic reasons
> why CERTREQ etc are usuful in general. Anyways I think most ACP cases
> do not need CERTREQ, but on the other hand there might be cases where
> it is still useful there, and thats why I would hate to see profile
> that forbits its use. I.e., it is fine to say in profile, that
> CERTREQs might not be needed, but saying that they should/must not be
> sent is bad idea.
I hope that at no point do we forbid the use of anything.
A peer might not expect it/do anything.
The important part is that we say what pieces we *do* require.
There is one more revision of ACP coming out on Monday, and I hope that is
the last one that the IESG will approve on the next telechat.
>> In the case that you describe (RSA->ECDSA), I think that we would sign
TA1
>> with TA2, or vice-versa. (probably one and then the other a month later).
>> We can feed/update the trust anchors when certificates are renewed, or
we can
>> use draft-ietf-netconf-trust-anchors to change things (the advantages of
>> having really good security for in-band management)
> If you have proper management, then you can do almost instanteneous
> changes, but CERTREQ allows you do do similar things even when you do
> not have any kind of management system configuring devices, with much
> longer overlaps in configuration.
I think that proper management will probably not be in revision 1 of products.
However, a killer-use-case for the ACP is for SDN control channels, so I
could be wrong.
>> I prefer relatively short expiries for certificates in the ACP
>> because <STAR reasons>. I think that all systems have to support
>> both RSA and ECDSA for a big overlapping period. I don't think this
>> is a problem.
>>
>> I think that there is not a problem having a RSA key (TA1) sign an
>> ECDSA EE cert. I know that I've done it, but I know that some think
>> it uncool.
> Sometimes the problem is that there are devices there which do not
> support ECDSA at all, which means you are stuck with RSA for both root
> and EE for all devices. With CERTREQ some parts of the network can
> start use full ECDSA TA and EE and still interoperate with those
> devices which support both and get the "coolness" factor of not using
> RSA at all :-)
I think that we say that we will tolerate RSA :-)
So you are right: there could be devices which do not do ECDSA on day one,
and in which case, you can't switch the keys at all.
> Other similar cases comes when you merge authorization domains
> together, i.e., two companies merge and they both had their own CAs
> before, and not all devices support both CAs, so you need to pick
> correct certificate one when talking to one or another device.
Yes, this is an important case.
>> So, we've been forced to use otherName, and this will cause new code in
some
>> of the IKEv2 daemon that we need to use :-(
> No, you are not forced to use anything. Your ID could be KEY_ID with
No, the ACP document has been forced to use otherName in it's
certificates. That's nothing to do with IPsec/IKEv2.
But, that that's what IKEv2 will have to deal with.
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
