

Found 2 records.
Errata ID: 3820
Status: Reported
Type: Editorial
Reported By: Nicolas Williams
Date Reported: 20131205
Section 3.2.2 says:
The type of the otherName field is AnotherName. The typeid field of the type AnotherName is idpkinitsan: idpkinitsan 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 typeid field of the type AnotherName is idkerberossan: idkerberossan 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 idpkinitsan for nonPKINIT 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 idpkinitsan should have been named idkerberossan, and should be referred to as idkerberossan 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 idpkinitsan in RFC4556, all of which should read idkerberossan instead.
Errata ID: 3157
Status: Held for Document Update
Type: Technical
Reported By: Tom Yu
Date Reported: 20120315
Held for Document Update by: Stephen Farrell
Section 3.2.1 says:
8. The client's DiffieHellman public value (clientPublicValue) is included if and only if the client wishes to use the Diffie Hellman key agreement method. The DiffieHellman domain parameters [IEEE1363] for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279], and the client's DiffieHellman public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279]. When using the DiffieHellman key agreement method, implementations MUST support Oakley 1024bit Modular Exponential (MODP) wellknown group 2 [RFC2412] and Oakley 2048bit MODP wellknown group 14 [RFC3526] and SHOULD support Oakley 4096bit MODP wellknown group 16 [RFC3526]. The DiffieHellman field size should be chosen so as to provide sufficient cryptographic security [RFC3766]. When MODP DiffieHellman 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 DiffieHellman public value (clientPublicValue) is included if and only if the client wishes to use the Diffie Hellman key agreement method. The DiffieHellman domain parameters [IEEE1363] for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279], and the client's DiffieHellman public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279]. When using the DiffieHellman key agreement method, implementations MUST support Oakley 1024bit Modular Exponential (MODP) wellknown group 2 [RFC2412] and Oakley 2048bit MODP wellknown group 14 [RFC3526] and SHOULD support Oakley 4096bit MODP wellknown 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 wellknown 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 wellknown 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 (P1)/2. The DiffieHellman field size should be chosen so as to provide sufficient cryptographic security [RFC3766]. When MODP DiffieHellman 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 DiffieHellman group when participating
in PKINIT. This happens for two wellknown 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).