public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
To: Qin Long <qin.long@intel.com>, ting.ye@intel.com, chao.b.zhang@intel.com
Cc: edk2-devel@lists.01.org
Subject: Re: [PATCH v2] CryptoPkg: Add new API to retrieve commonName of X.509 certificate
Date: Wed, 20 Sep 2017 18:38:08 +0200	[thread overview]
Message-ID: <bf5f4d76-971c-691f-a1d7-be339aa3e3a5@redhat.com> (raw)
In-Reply-To: <20170920160515.6792-1-qin.long@intel.com>

Hello Qin,

On 09/20/17 18:05, Qin Long wrote:
> v2: Update function interface to return RETURN_STATUS to represent
>     different error cases.
> 
> Add one new API (X509GetCommonName()) to retrieve the subject commonName
> string from one X.509 certificate.
> 
> Cc: Laszlo Ersek <lersek@redhat.com>
> Cc: Ting Ye <ting.ye@intel.com>
> Cc: Chao Zhang <chao.b.zhang@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qin Long <qin.long@intel.com>
> ---
>  CryptoPkg/Application/Cryptest/RsaVerify2.c        |  32 +++++--
>  CryptoPkg/Include/Library/BaseCryptLib.h           |  34 +++++++
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509.c      | 106 +++++++++++++++++++++
>  CryptoPkg/Library/BaseCryptLib/Pk/CryptX509Null.c  |  32 +++++++
>  .../Pk/CryptX509Null.c                             |  34 ++++++-
>  5 files changed, 230 insertions(+), 8 deletions(-)
> 
> diff --git a/CryptoPkg/Include/Library/BaseCryptLib.h b/CryptoPkg/Include/Library/BaseCryptLib.h
> index 9c5ffcd9cf..48e9531758 100644
> --- a/CryptoPkg/Include/Library/BaseCryptLib.h
> +++ b/CryptoPkg/Include/Library/BaseCryptLib.h
> @@ -2171,6 +2171,40 @@ X509GetSubjectName (
>    IN OUT  UINTN        *SubjectSize
>    );
>  
> +/**
> +  Retrieve the common name (CN) string from one X.509 certificate.
> +
> +  @param[in]      Cert             Pointer to the DER-encoded X509 certificate.
> +  @param[in]      CertSize         Size of the X509 certificate in bytes.
> +  @param[out]     CommonName       Buffer to contain the retrieved certificate common
> +                                   name string. At most CommonNameSize bytes will be
> +                                   written and the string will be null terminated. May be
> +                                   NULL in order to determine the size buffer needed.
> +  @param[in,out]  CommonNameSize   The size in bytes of the CommonName buffer on input,
> +                                   and the size of buffer returned CommonName on output.
> +                                   If CommonName is NULL then the amount of space needed
> +                                   in buffer (including the final null) is returned.
> +
> +  @retval RETURN_SUCCESS           The certificate CommonName retrieved successfully.
> +  @retval RETURN_INVALID_PARAMETER If Cert is NULL.
> +                                   If CommonNameSize is NULL.
> +                                   If Certificate is invalid.
> +  @retval RETURN_NOT_FOUND         If no CommonName entry exists.
> +  @retval RETURN_BUFFER_TOO_SMALL  If the CommonName is NULL. The required buffer size
> +                                   (including the final null) is returned in the 
> +                                   CommonNameSize parameter.
> +  @retval RETURN_UNSUPPORTED       The operation is not supported.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +X509GetCommonName (
> +  IN      CONST UINT8  *Cert,
> +  IN      UINTN        CertSize,
> +  OUT     CHAR8        *CommonName,
> +  IN OUT  UINTN        *CommonNameSize
> +  );
> +
>  /**
>    Verify one X509 certificate was issued by the trusted CA.
>  

I think the RETURN_BUFFER_TOO_SMALL description is incorrect -- it
shouldn't only cover the (CommonName == NULL) case, but any other case
when *CommonNameSize is not large enough, for formatting the full CN,
plus the terminating '\0'.

Relatedly, the output value of *CommonNameSize should always be the
number of bytes required to format the NUL-terminated common name,
regardless if there is enough room or not. The return status will tell
the caller:
- if the return status is BUFFER_TOO_SMALL, then a larger buffer is
needed -- how large is explained by *CommonNameSize
- if the return status is SUCCESS, then the buffer was large enough, and
*CommonNameSize bytes have been used from it.

Additional question: does the code handle the case when *CommonNameSize
is zero, on input? (I.e., when there isn't even room for storing a '\0'
character.)

Thanks,
Laszlo


  reply	other threads:[~2017-09-20 16:35 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-20 16:05 [PATCH v2] CryptoPkg: Add new API to retrieve commonName of X.509 certificate Qin Long
2017-09-20 16:38 ` Laszlo Ersek [this message]
2017-09-20 17:04   ` Long, Qin
2017-09-20 17:12     ` Laszlo Ersek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bf5f4d76-971c-691f-a1d7-be339aa3e3a5@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox