# RFC Errata

Found 2 records.

## Status: Reported (1)

#### RFC 4556, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", June 2006

**Note: This RFC has been updated by RFC 6112, RFC 8062, RFC 8636**

Errata ID: 3820

**Status: Reported
Type: Editorial
Publication Format(s) : TEXT**

Reported By: Nicolas Williams

Date Reported: 2013-12-05

Section 3.2.2 says:

The type of the otherName field is AnotherName. The type-id field of the type AnotherName is id-pkinit-san: id-pkinit-san OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) x509SanAN (2) }

It should say:

The type of the otherName field is AnotherName. The type-id field of the type AnotherName is id-kerberos-san: id-kerberos-san OBJECT IDENTIFIER ::= { iso(1) org(3) dod(6) internet(1) security(5) kerberosv5(2) x509SanAN (2) }

Notes:

The certificate subject alternative name (SAN) type added by RFC4556 is and has been used more generically than its symbolic name denotes.

Note that there is no risk in using id-pkinit-san for non-PKINIT purposes as presence of that SAN is -naturally- insufficient by itself to cause an AS to issue a ticket to the client for the named principal. RFC4556 is quite clear on this point.

Therefore id-pkinit-san should have been named id-kerberos-san, and should be referred to as id-kerberos-san going forward. (If there was a registry of PKIX certificate extensions we would additionally ask IANA to updte it.)

There are a few other mentions of id-pkinit-san in RFC4556, all of which should read id-kerberos-san instead.

## Status: Held for Document Update (1)

#### RFC 4556, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", June 2006

**Note: This RFC has been updated by RFC 6112, RFC 8062, RFC 8636**

Errata ID: 3157

**Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT**

Reported By: Tom Yu

Date Reported: 2012-03-15

Held for Document Update by: Stephen Farrell

Section 3.2.1 says:

8. The client's Diffie-Hellman public value (clientPublicValue) is included if and only if the client wishes to use the Diffie- Hellman key agreement method. The Diffie-Hellman domain parameters [IEEE1363] for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279], and the client's Diffie-Hellman public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279]. When using the Diffie-Hellman key agreement method, implementations MUST support Oakley 1024-bit Modular Exponential (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit MODP well-known group 16 [RFC3526]. The Diffie-Hellman field size should be chosen so as to provide sufficient cryptographic security [RFC3766]. When MODP Diffie-Hellman is used, the exponents should have at least twice as many bits as the symmetric keys that will be derived from them [ODL99].

It should say:

8. The client's Diffie-Hellman public value (clientPublicValue) is included if and only if the client wishes to use the Diffie- Hellman key agreement method. The Diffie-Hellman domain parameters [IEEE1363] for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279], and the client's Diffie-Hellman public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279]. When using the Diffie-Hellman key agreement method, implementations MUST support Oakley 1024-bit Modular Exponential (MODP) well-known group 2 [RFC2412] and Oakley 2048-bit MODP well-known group 14 [RFC3526] and SHOULD support Oakley 4096-bit MODP well-known group 16 [RFC3526]. Some implementations are known to omit the mandatory Q value from the DomainParameters (in the algorithm value of the clientPublicValue) when using the well-known MODP groups 14 and 16, which can cause an ASN.1 decoding error for the DomainParamters value. While [RFC3526] does not explicitly specify the Q value for the well-known MODP groups 14 and 16, the prime modulus of each of these groups is a safe prime -- having the form P = 2Q + 1, where P and Q are prime. Therefore, the Q value for each of these moduli is the corresponding Sophie Germain prime, and it is equal to (P-1)/2. The Diffie-Hellman field size should be chosen so as to provide sufficient cryptographic security [RFC3766]. When MODP Diffie-Hellman is used, the exponents should have at least twice as many bits as the symmetric keys that will be derived from them [ODL99].

Notes:

The new paragraph identifies an interoperability problem where an

implementation omits the Q value (required in the DomainParameters

type defined in RFC3370) of a Diffie-Hellman group when participating

in PKINIT. This happens for two well-known IKEv2 MODP groups that are

defined in RFC3526, probably because RFC3526 does not explicitly state

the Q values for the moduli. The moduli are safe primes, so the new

text specifies how to compute their Q values (which are the

corresponding Sophie Germain primes).