Hi Paul,
> > 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.
We do support PKCS#7 too, but officially it's not specified for IKEv2 and
thus must not be specified in the profile.
> > 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.
That was my point :-)
> > 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?
Agree.
> > 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" ?
No, as far as I understand the text, it tells that the particular
signing algorithm is indicated in the AUTH payload by inclusion its OID.
That's partially true, it is indicated by inclusion AlgorithmIdentifier ASN.1
object
(and not SubjectPublicKeyInfo or pure OID).
It's probably better to just delete the text in the last sentence "as indicated
by a PKIX-style OID".
Regards,
Valery.
> Paul
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
