Re: [kmip] Locating Certificates Using KMIP

[Mike Allen <Mike_Allen@symantec.com>]

Of course, PGP keys make this all the more complex.  :)

In the PGP world, keys (which would be equivalent to the term
"certificate" for the purposes of this thread) can have many IDs (read
"subjects") associated with them, each of which may or may not be signed
in a verifiable way (i.e. by a key/cert you trust).  So, Judy, when you
talk about searching for the certificate subject below, in the context of
PGP keys, there may be many such IDs associated with one particular
cryptographic object.

Participants in the PGP universe of keys are typically doing lookups
against key servers to find the public keys of recipients for messages
(usually emails).  I would say that those searches comprise about 95% of
all searches done for PGP keys.  The rest would be looking up your own key
by various attributes, but most often by your own identity.

For the purposes of KMIP, having the Locate call by Certificate Subject
take only one value is probably sufficient, as most of the time you are
only looking up a key for one particular ID (an email address or the
like).  However the KMIP servers would need to be aware that each key can
contain many IDs, and one could argue that the KMIP protocol should also
make all these IDs available for clients.  The only other way to get at
them would be to crack open the PGP key block itself once it was
downloaded, which probably isn't ideal.

In regards to the Certificate Length versus Cryptographic Length issue, I
think it makes perfect sense to have the two be separate values.  Knowing
that the key represented by this certificate is 1024 bits while the
certificate itself is 2943 bytes long makes complete sense.  (Of course,
the units change in there; if that's not explicitly stated it should be).

-= Mike =-

On 8/3/11 1:10 PM, "judith.furlong@emc.com" <judith.furlong@emc.com> wrote:

>I haven't seen anyone post use cases for how they wish to locate
>Certificates to the reflector so I figured I'd start the discussion by
>looking at what we can do today with the KMIP v1.0 specification and what
>we may be able to do with some proposed changes for v1.1.
>
>In v1.0 of KMIP we have four attributes which are specifically related to
>certificates: Certificate Type, Certificate Identifier, Certificate
>Subject and Certificate Issuer.  In addition there are other attributes
>such as Digest, Cryptographic Algorithm, Cryptographic Length and
>Cryptographic Parameters which are also specified in v1.0 as applying to
>certificates.  Leaving the Cryptographic Algorithm, Cryptographic Length
>and Cryptographic Parameters attributes aside for the moment let's look
>at the type of queries we can make using the Locate operation to find
>certificates with any of the five other attributes:
>*       Using Certificate Type one could ask for all X.509 or all PGP
>certificates which are available.
>*       Using Certificate Identifier you can locate a specific
>certificate.
>*       Using Certificate Issuer you can find all the certificates that
>were issued by a specific CA.  This would be useful if the CA was
>compromised and your trying find all the affected certificates.
>*       Certificate Subject can be used to find all certificate which are
>associated with a specific entity (aka the subject of the certificate).
>*       Digest could be used to find a specific certificate with a
>specified digest (aka fingerprint).
>You can also do more complex searches by specifying multiple attributes
>in the Locate command.  This way you can pare down the list of results.
>Examples include:
>*       You can combine Certificate Type with Certificate Subject to find
>all the X.509 or PGP certificates belong to a specific entity.
>*       You could combine Certificate Subject and Certificate Issuer to
>find all the certificates issued by a specific CA to a specific entity.
>
>For the v1.1 specification we were looking to clarify the confusion
>associated with what the Cryptographic Algorithm, Cryptographic Length
>and Cryptographic Parameters attributes mean in the context of
>certificates.  The Digital Signature Algorithm proposal which I submitted
>added a new attribute that would be associated with a Certificate (in the
>future (post v1.1) it may be an attribute used in other KMIP contexts)
>that would identify the signature alorithm used in signing the
>certificate.   So with this attribute you could now use the Locate
>operation to find all certificates signed using a specific digital
>signature algorithm.  Or in a compound locate you could find all
>certificates issued by a specific CA (Certificate Issuer) and signed
>using a specific algorithm (Digital Signature Algorithm).
>
>Now the Digital Signature Algorithm proposal went a step further stating
>that Cryptographic Algorithm attribute would no longer be associated with
>Certificates.   This was a reasonable approach since Digital Signature
>Algorithm is a more accurate description of the algorithm associated with
>the certificate object itself.  But if you want to record what algorithm
>is associated with the Subject Public Key contained in the certificate,
>dropping this attribute now result in a limitation.  We could clarify the
>specification to state that both the Digital Signature Algorithm and the
>Cryptographic Algorithm attributes are associated with certificates.  The
>Digital Signature Algorithm attribute would hold the signature algorithm
>used in signing the certificate (specified in the signature field of the
>certificate) and the Cryptographic Algorithm attribute would hold the
>asymmetric algorithm associated with the subject public key (specified in
>the subjectPublicKeyInfo field of the certificate).  With this approach
>you could then search for all certificates containing subject public keys
>for a certain algorithm (e.g. RSA) by specifying the Cryptographic
>Algorithm attribute.
>
>I also submitted a proposal that clarified what the Cryptographic Length
>means in the context of Certificates.  This proposal suggested that this
>attribute contain the length of the certificate itself, but based on the
>discussion during the call last week there didn't seem to be a great
>demand for knowing the length of the certificate itself.  However there
>was interest in finding certificate containing subject public keys of a
>certain length (e.g. find all 1024 bit RSA keys).  If this is the case
>then we could propose that the Cryptographic Length associated with a
>Certificate contain the length of the subject public key contained in the
>certificate.  This would be in-line with the suggestion in the previous
>paragraph of having the Cryptographic Algorithm associated with the
>certificate contain the algorithm of the subject public key contained in
>the certificate.  The question I have for the TC is whether anyone has a
>strong use case for having an attribute to contain the length of the
>certificate itself?  If there are use cases then we can introduce a new
>attribute 'Certificate Length' to carry this value.
>
>That leaves the Cryptographic Parameters attribute for which no proposal
>has been submitted.  I would suggest that we keep all the 'Cryptographic
>*' attributes in-line for certificates and specify that the Cryptographic
>Parameters attribute contain the parameters associated with the Subject
>Public Key contained in the certificate.
>
>I'd be interested in hearing folks opinions on these revised changes to
>the v1.1 specification prior to redrafting the Digital Signature
>Algorithm and Certificate Length proposals.
>
>Are there other Locate related issues for certificates that we need to
>consider and are there additional attributes we should associate with
>certificates?
>
>Are there Locate related issues for objects other then certificates that
>need to be discussed?
>
>Judy
>
>Judith Furlong | Consultant Product Manager | EMC Product Security Office
>| RSA , The Security Division of EMC | office: +1 508 249 3698 | email:
>Judith.Furlong@emc.com<mailto:Furlong_Judith@emc.com>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>