Paul Wouters <p...@nohats.ca> wrote:
> I agree it should not try to dictate how certificate based IKE
> certification works, but just reference to IKEv2 and its updates for
> that.
+1
>> Another point: trust anchors certificates usually are not
>> included in CERT payload in IKEv2. I see draft’s a reasoning
>> that this inclusion would allow better network debugging, but I’m
>> not sure I can buy this argument. Probably more detailed
>> explanation is needed.
> They could suggest that for easier debuggint a CERTREQ payload is
> included. That has the hash of the CA, which should be good enough.
> But again, IKEv2 already specifies this. Why is this document trying to
> change IKEv2 certificate processing?
By construction, all the certificates in the ACP should be from the same CA.
But, there may be edges that connect to other domains (ISP peering points,
for instance), and it could be that they attempt to connect. That ought to
fail.
What I want, is the knowledge of what the anchors were.
I agree, we could instead include a CERTREQ.
>> 3. IKEv2 authentication MUST use authentication method 14 ("Digital
>> Signature") for ACP certificates; this authentication method can be
>> used with both RSA and ECDSA certificates, as indicated by a PKIX-
>> style OID. I think it’s better to rephrase this more
>> accurately: “indicated by an ASN.1 object AlgorithmIdentifier”
> Wouldn't it be more correct to say "indicated by a SubjectPublicKeyInfo
> (SPKI) ASN.1 object" ?
I have no opinion here.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
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
