Menu
▾
▴
#12 Support all 3 RFC 4210 section 4.1 POP methods
From RFC 4210 D.3's last sentence it seems as if clients need to implement all 3 cases of RFC 4211 4.1 need to be fully RFC compliant.
So far only case 3 is supported (see crmf/crmf_lib.c).
Case 1 seems to be needed for IR with user/pass where the EE subject name is not yet known
Case 2 seems to be needed for IR when the EE desires a new subject name or expects to get a different one by the CA anyway (and therefore doesn't set its currently known one)
Case 3 is when the EE knows its own subject name
Reading sections 4.1/4.2 of RFC 4211 I start to wonder what the official definition of "signature key" and "key encipherment key" is. It might relate to section 4.2.1.3 of RFC 5280 (Key Usage extension) but how would be the matching? And would the EE always know what the CA will decide to put into that extension? Luckily RFC 4210 D.3 seems to restrict that to the options given in RFC 4211 4.1, so only "signature key"s are there in CMP. but then why is POPOPrivKey mentioned in RFC4210 C. Weird.
Ticket moved from /p/cmpforopenssl/bugs/13/