Subject: Extended Key Usage for OCSP signing and IPSEC

From: Eamonn Maher <[email-masked]>
Date: Wed, 28 Jul 1999 13:46:35 +0100

1. 
If the ExtendedKeyUsages extension is critical then it must be consistent with 
the KeyUsage extension (if present and critical - which it SHOULD be). Then 
what KeyUsage bits should be set if the extension contains the OCSP signing 
OID? just digitalSignature?

2.
Why are the extended key purpose OIDs for IPSEC (id-kp-ipsecEndSystem,
id-kp-ipsecTunnel and id-kp-ipsecUser) defined in rfc 2459?
In 
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-pki-req-02.txt
only iKEEnd and iKEIntermediate are defined.

3.
What valid combinations are there of KeyUsage and the above PKIX IPSEC 
extendedKeyUsages and the IPSEC extendedKeyUsages?

Eamonn

---

From: "William Whyte" <[email-masked]>
Date: Wed, 28 Jul 1999 14:05:50 +0100

And in a good day for questions from Baltimore...

There seems to be an inconsistency between X9.42 and RFC 2459 about
how to encode Diffie-Hellman public keys. RFC 2459 says this:

   The Diffie-Hellman public key shall be ASN.1 encoded as an INTEGER;
   this encoding shall be used as the contents (i.e., the value) of the
   subjectPublicKey component (a BIT STRING) of the subjectPublicKeyInfo
   data element.

which, to me, reads like you end up with a BIT STRING, containing an
INTEGER, containing the data. On the other hand, X9.42 says this:

   The public key (an INTEGER) is mapped to a subjectPublicKey (a BIT 
   STRING) such that the most significant bit of the INTEGER becomes 
   the most significant bit of the BIT STRING and the least significant
   bit of the INTEGER becomes the least significant bit of the BIT STRING.
   The integer therefore remains encoded in "big-endian" format. If the 
   integer is not an integral number of octets in length, the BIT STRING 
   encoding indicates the number of unused bits in the last octet of the 
   encoding.

which reads like you take the ASN.1 INTEGER, strip off the tag, left-shift 
it until the most significant bit is set, and then encode it as a BIT
STRING with the appropriate number of unused bits, not containing an
INTEGER at all.

The PKIX version is consistent with the treatment of DSA (BIT STRING
wrapping INTEGER) and RSA (BIT STRING wrapping SEQUENCE). The X9.42
version saves up to four bytes, but is very annoying to implement because
of the left-shifting. But they definitely seem to be saying different
things.

Am I reading both standards right? My copy of X9.42 dates from October
last year -- is that the source of the problem?

Cheers,

William

---

From: Paul Koning <[email-masked]>
Date: Wed, 28 Jul 1999 11:29:51 -0400

>>>>> William Whyte <[email-masked]> writes:

> ...
> On the other hand, X9.42 says this:
> 

I don't read it quite that way.  It says "most significant bit", it
does NOT say "most significant bit that is set".  If the key length is 
K, regardless of whether there are leading zero bits, the shift is by
(8-K) MOD 8.

	paul

---

From: "William Whyte" <[email-masked]>
Date: Wed, 28 Jul 1999 16:35:49 +0100

Hi,

> K, regardless of whether there are leading zero bits, the shift is by

Well, there's two things there:

1) A BER-encoded integer doesn't have trailing unused bits in the last
   byte. If you weren't expected to left-shift, surely it would say
   something like "the BIT STRING encoding should indicate zero unused
   bits in the last octet". And note that it says "If the integer is not 
   an integral number of octets in length", not "If the INTEGER..."; the
   implication is that we're dealing with the raw data.

2) Be that as it may, the X9.42 spec definitely seems to be telling us
   to throw away the INTEGER tag, and the PKIX spec definitely seems to
   be telling us to keep it. 

Like I say, I prefer the PKIX approach, but a resolution really depends
on the X9 folk.

Cheers,

William

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 28 Jul 1999 09:49:34 -0700

On (2) 

Warwick asked some people at the Memphis IETF
what key purposes relevant to IETF work should
be defined. I suggested those two represent
the controlled use of the (then) known sets of security 
services, optionally governed by certs, for IPSEC 
virtual network tunnelling and IPSEC user 
authentication to the network/VPN. The then
chair of IPSEC agreed, whilst drinking down
his beer. No-one objected during 2459 final call.

2459 is charged with addressing standard
internet apps/protocols (versus non IETF apps/protocols such
as secure media-based workflow, and web stuff.) IPSEC 
seemed to fit the bill, and therefore 
fell in the profile scope. There are other
application security contexts for IPSEC which
should probably have also been named. One can
use private oids, for these, however. Like
for certificate politicies, IETF NEED not be involved 
in the OID value assignment; vendors and user
organizations can do this outside the standard.
Should IPSEC WG desire to formalize oids for
securing different types of store-and-forward 
inter-network links (for secure routing and 
route selection, presumably),  this seems another 
perfectly reasonable use of the PKI technique.

> -----Original Message-----
> From: Eamonn Maher [mailto:[email-masked]]
> Sent: Wednesday, July 28, 1999 5:47 AM
> To: [email-masked]
> Subject: Extended Key Usage for OCSP signing and IPSEC
> 
> 
> 1.