The "uniquely identifies" clause really only applies to the
issDN/serialNum bit. Moving it gives:
A recipient independently computes the message digest. This message
digest and the signer's public key are used to verify the signature
value. The signer's public key is referenced either by an issuer
distinguished name along with an issuer-specific serial number
that uniquely identifies the certificate containing the public
key or by
a subject key identifier.
-----Original Message-----
From: owner-ietf-pkix(_at_)mail(_dot_)imc(_dot_)org
]
On Behalf Of Sean Turner
Sent: Thursday, March 26, 2009 2:58 PM
To: Jan Vilhuber
Cc: ietf-pkix(_at_)imc(_dot_)org
Subject: Re: Nitpicking between CMS and CMC
I think mandating a self-signed certificates is not the way to go.
spt
Jan Vilhuber wrote:
I noticed the following discrepancy between CMC and CMS, which
could
very accurately be described as nitpicking (but them isn't that
what
standards are about?):
CMS RFC, section 5. Signed-data Content Type:
<quote>
A recipient independently computes the message digest. This
message
digest and the signer's public key are used to verify the
signature
value. The signer's public key is referenced either by an issuer
distinguished name along with an issuer-specific serial number or
by
a subject key identifier that uniquely identifies the certificate
containing the public key. The signer's certificate can be
included
in the SignedData certificates field.
</quote>
Specifically: "... or by a subject key identifier that uniquely
identifies the certificate containing the public key".
CMC RFC, Section 3.2. Full PKI Request
<quote>
If SignedData is used, the signature can be generated using
either the
private key material of an embedded signature certification request
(i.e., included in the TaggedRequest tcr or crm fields) or a
previously
certified signature key. If the private key of a signature
certification
request is used, then:
a. The certification request containing the corresponding public
key
MUST include a Subject Key Identifier extension
b. The subjectKeyIdentifier form of the signerIdentifier in
SignerInfo MUST be used.
c. The value of the subjectKeyIdentifier form of SignerInfo MUST
be
the Subject Key Identifier specified in the corresponding
certification request. (The subjectKeyIdentifier form of
SignerInfo is used here because no certificates have yet been
issued for the signing key.) If the request key is used for
signing, there MUST be only one SignerInfo in the SignedData.
</quote>
So CMC allows the SignedData to use the SubjectKeyIdentifier, but
pointing to the certificate request it is encapsulating. While I
don't
mind this usage, the CMS rfc specifically mentions that the
SubjectKeyIdentifier "uniquely identifies the certificate
containing the
public key".
So if we want to be nitpicky about it, then the CMC rfc is asking
for
something which is illegal as per the CMS RFC. This can be
cleaned up in
either place, i.e. either mandating in CMC that a self-signed
certificate be included when no previous certificate has been issued
(thus making it conform to CMS), or modify CMS to allow a more
liberal
application of where to find the public key in question.
Thoughts?
jan