On Wed, 26 Feb 2020, Valery Smyslov wrote:
1. The
Certificate Encoding "PKCS #7 wrapped X.509 certificate" (1) MUST be
supported. See [IKEV2IANA] for this and other IANA IKEv2 parameter
names used in this text.
“PKCS #7 wrapped X.509 certificate” certificate encoding is deprecated and
is not used in IKEv2
(see
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-11).
Generally, I see no need for the text that imposes requirements on
certificate encoding at all –
we never run into the interoperability problems with this? as far as I
remember. I suggest to remove
this text.
Actually we do. We had to add pkcs7 to ikev2 to be compatible with some
windows deployments when intermediate certificates were being sent. On
top of that, Microsoft did it wrong, as the format does not allow a
chain but they added more than one anyway. So if anything, we DO NOT
want to see more pkcs7 in IKEv2.
2. If certificate chains are used, all intermediate certificates up to,
and including the locally provisioned trust anchor certificate MUST
be signaled. See Section 6.10.7 for the sub-CA example in which
certificate chains are used.
This is confusing. I read this text as the “MUST” is imposed only if
“certificate chains are used”. Does it mean that implementations
may skip this “MUST” if EE certificate is directly signed by CA certificate
and there is no intermediate certificates? Or is it still a chain
and “if” is relevant to the case when there is no CA and there is a direct
trust to EE certificates
(in which case PKI is not needed at all and you can use RAW public keys)?
I agree it should not try to dictate how certificate based IKE
certification works, but just reference to IKEv2 and its updates for
that.
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?
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" ?
Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
