[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names
I misspoke, 'proposed' not 'standard' was the proper term. In Raleigh we
found that most implementors found the subjectAltName proposal preferable
over using some mechanism to use the subjectName. I myself just wanted to
define rules for formatting subjectName (which would have allowed regex
matching). So we already had this discussion once (not to mean at all that
we should not be visiting the subject now, as it's on the main list...)
At 12:24 PM 9/11/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.
>
>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.
Well then I worded the text wrong. I meant two different algorithms. I'll
change the text. Or are you saying RSA and DSA and ECC are the same thing
(which I'm sure the RSA lawyers would love to hear :-))
>
>
>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.
>
yeah fine I'll change it.
>
>Could you change the wording of the third paragraph of section 3.2 to say:
>
>A root signing certificate
> ^^^^
No. If it's not at the top of the hierarchy then it's not a root.
Been there, got that wrong. You might not like my mandating 8 layers, and
that's fine, but
I am positive we'll need to deal with more than one-layer hierarchies.
>
>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.
right.
>
>
>-dmason
>
References: