[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Latest ipsec-pki-req-04.txt - EKU
Rodney Thayer wrote:
> I guess we've been staring at this too long. Let's try this
> I wanted ONE eku in a cert. I think it is INSECURE to have
> "swiss army knife" certificates that do multiple functions.
> This comment applies to SMIME, IPsec, TLS -- any cert usage.
I think that in some environments, having "swiss army knife" certs
could potentially be insecure. I don't agree that we should construct
a requirements statement that says that Swiss Army Knife certificates
There are some environments where issuing a certificate-per-application
is operationally inconvenient, and bordering on impossible.
Consider a corporate environment, where "them that is in charge" issue
certs for use by all applications. What is the semantic difference between
a bunch of certificates issued by "them", each one asserting:
"This is Marcus Leech [for S/MIME purposes]" -- Signed "them"
"This is Marcus Leech [for IPSEC purposes]" -- Signed "them"
"This is Marcus Leech [for TLS purposes]" -- Signed "them"
"This is Marcus Leech [for S/MIME, IPSEC, TLS, FOO purposes" -- Signed "them"
For one thing, existing crypto token technology has limited storage capability,
and if one assumes different private keys for each of the application-specific
certs, you quickly run out of storage on your tokens. Storage capacity
in token technology isn't exactly racing along like a rabit, and no amount
of us wishing it were so [or engineering protocols to make it necessary]
is going to change that.
> I believe (some PKIX lawyer check me on this...) that 2459 allows
> any number of EKU's (wanna parse a cert with 572 EKU's, anyone?
> Can you say "architecturally irresponsible"?)
That's certainly the way I read RFC2459. While I certainly am personally
repulsed at the though of needing 572 EKU's in a certificate, I can't
see why parsing 572 is any more difficult than parsing 1, once you
have the machinery in the code. Will it take longer? Yes, but certainly
nowhere near what it takes to do cert chain validation...
> I believe we got the text wrong, as I believe the rough consensus on
> this is that it should say...
> In a certificate for an IPsec end entity, the extendedKeyUsage field
> (commonly called "EKU") SHOULD be present. In order to indicate this
> certificate is allowed to be used for IPsec, it MUST contain the
> object identifier iKEIntermediate
> (iso.org.dod.internet.security.mechanisms.ipsec.certificate.2, or
> 22.214.171.124.126.96.36.199.2). An IKE system that conforms to this profile SHOULD
> NOT accept end-entity certificates that do not follow this rule.
> Now, I realize we're going around in circles on this, so I expect others
> to shout this down and that first 'MUST' (see my * above) will be watered
> down to a SHOULD.
I disagree that we need to even say "SHOULD"--such decision is an operational
one based on the environment. The protocol should be agnostic on this.
Operationally, I'm using certificates that don't have ANY EKU at all.
I sure as heck don't want to have an interoperability failure because
the certs I've been issuing for other purposes for several years are
suddenly worthless to me for IPSEC because of the WG decided that
an IKE EKU was necessary, and my IPSEC vendor went along with it.
Should I be able to configure my IPSEC implementation to insist on
certain things being present in the certificate? Absolutely! Should
the WG mandate certain things? Only when functionality and interoperability
cannot be delivered in any other way. Similarly, I should be able to
configure my CA/certificate-issuing-machinery to set things in the cert
that allow me to do good things. These should be based on my own
operational policy, and not a policy that the WG thinks is "cool".
Marcus Leech Mail: Dept 8M70, MS 012, FITZ
Systems Security Architect Phone: (ESN) 393-9145 +1 613 763 9145
Security and Internet Solutions Fax: (ESN) 395-1407 +1 613 765 1407
Nortel Networks firstname.lastname@example.org
-----------------Expressed opinions are my own, not my employer's------