[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names
>>Can someone give me a real-life example of how having the subjectAltName
>>field closes a security hole that exists when the subjectAltName field
>>isn't present?
>
>subjectAltName is the (standard) way to present the IP address, if you
>want to match the IP address in the ID payload to the certificate.
Don't you mean proposed standard:?) The certificate they use identifies
them and determines what type of connections (algorithm(s), local address(es),
remote address(es), etc.) they're allowed to setup. The database would of
course determine what local sites they're allowed access to and for
certificates of non-mobile peers part of the database would state the
peer addresses they're allowed to connect from. With the right
certificate-based policy database, matching a remote ip address to a
certificate without the use of a subjectAltName field is not that difficult
(it's just a subject/issuer DN regex match of certificate to database).
The only advantage of the subjectAltName field that I can see is that
it allows you to deny the connection without having to consult the
policy database if the subjectAltName is an IP address and it doesn't
match the source IP address of the sender. Lots of people seem to
really like subjectAltName so there must be other advantages I'm
missing here. Actually, since the certificate identifies the peer
and determines the policy to apply to the connection(s) I'm not really
sure why you even need an ID payload in phase I when using certificates
especially if it's mandated to be just a redundant copy of contents
within the certificate (if it's just a copy of what's in the certificate
why not just use the certificate?).
>>Does stating that the PKI MUST provide for the use of at least two public
>>key technologies (section 2.1) mean that IPSec devices MUST always have at
>>least two usage certificates with differing public key technologies? If
>>not, why is having two public key technologies required for a PKI
>>cryptographically sound environment but not for an IPsec device
>>cryptographically sound environment?
>
>well all those DES-only boxes out there that couldn't trivially switch to Triple DES or something else were somewhat inconvienced by the DES cracker...
Yes, but if those des-only boxes had been required to support two different
56-bit key technologies they probably wouldn't be any better off today
because of it.
I would prefer wording something like this (yes, I know the second sentence
is redundant) for the paragraph that starts "IPSec devices MUST support a
signing hierarchy ..." in section 2.2:
IPSec devices SHOULD support interaction with peers from many (at
least 8) different signing hierarchies. That is, IPSec devices SHOULD
support peer certificate validation against many (at least 8) different
root certificates.
Could you change the wording of the third paragraph of section 3.2 to say:
A root signing certificate
^^^^
And maybe add the following sentence to the end of section 4.4.1 (or maybe
in the Terminology section 1.1):
A 'Root' Signing Certificate is also sometimes referred to as a self
signed certificate.
-dmason
Follow-Ups: