RE: [pkcs11] Trust Objects draft 2â comments

I pulled the document from the Wiki. So it is an older version.

The latest version does have this update.

Thanks

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Wednesday, February 15, 2023 2:49 PM
To: pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Trust Objects draft 2â comments

On 2/15/23 4:54 AM, JOHNSON Darren wrote:

Hi,

overall the proposal looks good. I only have one clarification question.

For X.509 certificates, we have this:

CKA_ISSUER

Byte array

DER-encoding of the certificate issuer name (default empty)

For Trust objects we have this:

CKA_ISSUER¹

Byte Array

DER-encoding of the attribute certificate's issuer field. This is distinct from the CKA_ISSUER attribute contained in CKC_X_509 certificates because the ASN.1 syntax and encoding are different. (default empty)

I have very little experience with the various attributes we define for certificates in the spec. The provider I work with have very little support in this area. So acting like someone new to the specification, it is not clear to me what difference is being highlighted here.

Are you looking at the latest version of the spec? I thought I changes it to be the same as the X.509 description based on a previous review.

X.509 defines the issuer field as a âX.501 Nameâ, with its ASN.1 definition and everything that can be included under that ANS.1 tree.

So in the first case (the current spec), what is meant by âDER-encoding of the certificate issuer nameâ? I would have naively assumed it was the full binary data represented by âNameâ which is highlighted below. Is that not the case? And if not, then what is it?

   TBSCertList ::= SEQUENCE {

        version                 Version OPTIONAL,

                                     -- if present, MUST be v2

        signature               AlgorithmIdentifier,

        issuer                  Name,

And the follow up questionâ for the trust object, what is meant by âDER-encoding of the attribute certificate's issuer fieldâ. Again, to me, the issuer field would be the full binary data represented by âNameâ which is highlighted above. And if not, then what is it?

Thanks.

From: pkcs11@lists.oasis-open.org <pkcs11@lists.oasis-open.org> On Behalf Of Robert Relyea
Sent: Thursday, February 9, 2023 11:14 AM
To: Dieter Bong <Dieter.Bong@utimaco.com>; pkcs11@lists.oasis-open.org
Subject: Re: [pkcs11] Groups - Pub from Priv draft 2 uploaded

On 2/8/23 3:38 AM, Dieter Bong wrote:

Bob, all,

Here my questions and comments to the Pub-from-Priv proposal:

Line 204: typo Pubic -> Public

That's typo we should scan for in our overall document!

Line 218: Should CKA_DESTROYABLE default to CK_FALSE? Or should it be set to CKA_DESTROYABLE of the private key?

This is one that needs discussion. I figured the public key you generated was going to be a fresh copy and not something burned in a ROM somewhere. I suppose the token could implement it by having a non-destroyable copy in ROM already and just returning that, but in that case the application would have just found it with the CKA_ID (Well NSS would have anyway. It does the search before it calls PubFromPriv). Any that would be a case where the default could be token specific?

bob

pkcs11 message