At 10:46 AM +1000 6/26/10, Robert Loomans wrote:
...
The provisioning protocol uses PKCS #10 certificate requests, and
doesn't currently have any provision for PoP.
PKCS #10 includes provision for POP for keys/algs that support
signatures, e.g., RSA. RFC 5272 section 6.3 says:
Proof-of-possession information for key pairs, however, is carried
separately for each PKCS #10 or CRMF certification request. (For
keys capable of generating a digital signature, the POP is provided
by the signature on the PKCS #10 or CRMF request. ...)
Section 3.4.1 of the provisioning protocol says:
[Certificate request]
value is the certificate request. This is a Base-64 encoded
DER version of a request formatted using PKCS#10.
If one follows the usual PKCS #10 convention of signing the request
with the private key corresponding to the public key in the request,
we have PoP. I had assumed (perhaps erroneously) that the CMS
envelope would be signed using a BPKI key, for authorization purposes.
But, the nesting of all of this, including the XML, is complex, so ...
A diagram might help :-).
...
The key and algorithm info are in the certificate request. Is that enough?
In PKCS #10 these would refer to the key being certified by the
Issuer. What we need here is the ability to specify which of two
algs are to be used by the issuer. Again, I have never looked closely
at this document and thus I'm not sure to which specific fields you
are referring.
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
