[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
> again.
> 
> 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
  are disallowed.

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"

          vs

  "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
>   1.3.6.1.5.5.8.2.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                          mleech@nortelnetworks.com
-----------------Expressed opinions are my own, not my employer's------
Follow-Ups: References: