org.objectweb.carol.util.csiv2.gss

Class GSSHelper


public class GSSHelper
extends java.lang.Object

Handle RFC 2743 encoding

Author:
Florent Benoit

Method Summary

static String
decodeExported(byte[] toDecode)
static byte[]
decodeToken(byte[] toExtract)
3.1: Mechanism-Independent Token Format This section specifies a mechanism-independent level of encapsulating representation for the initial token of a GSS-API context establishment sequence, incorporating an identifier of the mechanism type to be used on that context and enabling tokens to be interpreted unambiguously at GSS-API peers.
static byte[]
encodeExported(String name)
Encode the given string into an array of byte By following RFC 2743
static byte[]
encodeToken(byte[] contextData)
Encode a given array of bytes by following RFC2743 3.1
static byte[]
getMechOidDer()

Method Details

decodeExported

public static String decodeExported(byte[] toDecode)
            throws Exception

Parameters:
toDecode - byte to decode

Returns:
a string corresponding to the decoding of the given array of bytes


decodeToken

public static byte[] decodeToken(byte[] toExtract)
3.1: Mechanism-Independent Token Format This section specifies a mechanism-independent level of encapsulating representation for the initial token of a GSS-API context establishment sequence, incorporating an identifier of the mechanism type to be used on that context and enabling tokens to be interpreted unambiguously at GSS-API peers. Use of this format is required for initial context establishment tokens of Internet standards-track GSS-API mechanisms; use in non-initial tokens is optional. The encoding format for the token tag is derived from ASN.1 and DER (per illustrative ASN.1 syntax included later within this subsection), but its concrete representation is defined directly in terms of octets rather than at the ASN.1 level in order to facilitate interoperable implementation without use of general ASN.1 processing code. The token tag consists of the following elements, in order: 1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that -- constructed form, definite length encoding follows. 2. Token length octets, specifying length of subsequent data (i.e., the summed lengths of elements 3-5 in this list, and of the mechanism-defined token object following the tag). This element comprises a variable number of octets: 2a. If the indicated value is less than 128, it shall be represented in a single octet with bit 8 (high order) set to "0" and the remaining bits representing the value. 2b. If the indicated value is 128 or more, it shall be represented in two or more octets, with bit 8 of the first octet set to "1" and the remaining bits of the first octet specifying the number of additional octets. The subsequent octets carry the value, 8 bits per octet, most significant digit first. The minimum number of octets shall be used to encode the length (i.e., no octets representing leading zeros shall be included within the length encoding). 3. 0x06 -- Tag for OBJECT IDENTIFIER 4. Object identifier length -- length (number of octets) of -- the encoded object identifier contained in element 5, -- encoded per rules as described in 2a. and 2b. above. 5. Object identifier octets -- variable number of octets, -- encoded per ASN.1 BER rules: 5a. The first octet contains the sum of two values: (1) the top-level object identifier component, multiplied by 40 (decimal), and (2) the second-level object identifier component. This special case is the only point within an object identifier encoding where a single octet represents contents of more than one component. 5b. Subsequent octets, if required, encode successively-lower components in the represented object identifier. A component's encoding may span multiple octets, encoding 7 bits per octet (most significant bits first) and with bit 8 set to "1" on all but the final octet in the component's encoding. The minimum number of octets shall be used to encode each component (i.e., no octets representing leading zeros shall be included within a component's encoding). (Note: In many implementations, elements 3-5 may be stored and referenced as a contiguous string constant.) The token tag is immediately followed by a mechanism-defined token object. Note that no independent size specifier intervenes following the object identifier value to indicate the size of the mechanism- defined token object. While ASN.1 usage within mechanism-defined tokens is permitted, there is no requirement that the mechanism- specific innerContextToken, innerMsgToken, and sealedUserData data elements must employ ASN.1 BER/DER encoding conventions. The following ASN.1 syntax is included for descriptive purposes only, to illustrate structural relationships among token and tag objects. For interoperability purposes, token and tag encoding shall be performed using the concrete encoding procedures described earlier in this subsection.

Parameters:
toExtract - the array of byte to decode

Returns:
the extracted token in bytes form.


encodeExported

public static byte[] encodeExported(String name)
Encode the given string into an array of byte By following RFC 2743

Parameters:
name - the given name to encode

Returns:
encoded string following RFC 2743 3.2 section


encodeToken

public static byte[] encodeToken(byte[] contextData)
            throws IOException
Encode a given array of bytes by following RFC2743 3.1

Parameters:
contextData - array to encode

Returns:
the decoded array of bytes


getMechOidDer

public static byte[] getMechOidDer()

Returns:
GSSUP mechOid in DER format