[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names
At 06:23 PM 9/10/98 -0400, you wrote:
>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.
>
>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...
>
>In section 2.2 what is the basis for the seemingly arbitrary number
>of 8 in the paragraph that starts "IPSec devices MUST support a signing
>hierarchy ...". I'm not really sure what is meant by this paragraph.
>Does it mean you must be able support the simultaneous use of eight
>or more root signing certificates or does it mean you must support
>signing chains of length up to 8 or longer?
must be able to support at least 8, don't have to use them all. I wanted some real number in there.
>
>In the next paragraph, why must all the certificates have the same
>key length? Why can't the root signing cert be 2048 and the usage
>cert be 1024? Why can't the IPsec device have a 1024 cert that it
>uses for most connections and a 2048 cert that it uses for connections
>requiring a greater level of security?
>
>Does the third paragraph of section 3.2 mean that IKE implementations
>should not accept or send certificate chains via IKE?
No, it means you shouldn't accept a root you didn't get in a secure manner. you can send the usage cert and the chain (except for the root) over IKE but you shouldn't send the root over IKE. "trust me, I'm certified, see? I just signed the root myself here on my PC...)
>
>-dmason
>
References: