Re: CMC Comments?

[Juergen Walter <walter@xxxxxx>]

Carlisle Adams wrote:
> 
> 
> 
> Apologies if the delay has kept you waiting.  As it turns out, getting
> these comments posted was not the only thing on my plate this week...
> 
> I have two primary concerns with respect to the latest draft of the CMC
> protocol (despite the fact that it is a vast improvement over previous
> iterations).  The first is the security of the initialization procedure.
> For signing key pairs, the reqSequence is a SEQUENCE OF taggedRequest,
> each of which could be a PKCS #10 or a CRMF structure (i.e., each
> element carries its own POP over the contents of the corresponding
> request).  In the controlSequence, an identityProof is computed over the
> full reqSequence.  The problem is that each individual request may carry
> no identity information (the draft explicitly says that the subject MUST
> be present, but may be NULL in order to accommodate environments in
> which names are centrally assigned (which makes sense to ensure
> uniqueness of DNs)).  Thus, the POP is computed over a structure without
> identity information.  This allows me to take the request and
> corresponding POP from someone else's message, put it in my own message,
> compute my identityProof over the request, and submit the result to the
> CA.  The CA then issues a certificate with my name and the "borrowed"
> public key.

[CRMF] defines the following.

"POPOSigningKeyInput ::= SEQUENCE {
    authInfo            CHOICE {
        sender              [0] GeneralName,
        -- used only if an authenticated identity has been 
        -- established for the sender (e.g., a DN from a
        -- previously-issued and currently-valid certificate)
        publicKeyMAC        PKMACValue },
        -- used if no authenticated GeneralName currently exists for
        -- the sender; publicKeyMAC contains a password-based MAC
        -- on the DER-encoded value of publicKey
    publicKey           SubjectPublicKeyInfo }  -- from CertTemplate 
"[CRMF]

Provided that there isn`t any password shared between subscriber and CA,
I miss the identifier (e. g. of the subscriber too. I agree that an
identifier for the subscriber should be present. The POP should include
any identifier for the applicant. But, I dislike the [CRMF] solution. I
would like to share between subscriber`s identifier on the one hand, and
some authentication token (e. g. password-based MAC) on the other hand.

The PKCS#10 request hasn`t any field that may serve a subscriber`s
identifier. Is someone interested in an attribute that contains a
subscriber`s identifier? What`s about an additional attribute that
contains an authentication token for initial registration? I was writing
authentication token, why I would like to break the restriction to this
one. The range of all authentication token should be allowed. 

[snip]

> - the draft does not specify the structure of an unsigned,
> shared-secret-based revocation request, while suggesting that there may
> be circumstances under which such a request will be a necessity (it says
> that the structure of such a request is "a matter of local
> implementation");
[snip]

This is a critical point. Revocation requests must be authenticated. One
way is that there are only signed revocation request are allowed. In
contrast, plain-text password authentication is bad. So, for
interoperability a secure mechanism is needed. 


Juergen Walter