Subject: [lamps] draft-ietf-lamps-cmp-updates section 3.8 using pkcs-9-at-localKeyId containing a revocation passphrase hint

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Wed, 6 May 2020 09:42:56 +0000

During IETF 107 we discussed whether to use pkcs-9-at-friendlyName or pkcs-9-at-localKeyId as specified in RFC 2985 section 5.5 in envelopedData to transport an identifier for the revocation passphrase.
The WG seemed to prefer the localKeyId.

@Jim, did you manage to take a look on this and do you have a different opinion?

-- Hendrik

---

From: Jim Schaad <[email-masked]>
Date: Wed, 6 May 2020 10:11:30 -0700

I would generally prefer the use of pkcs-9-at-localKeyId due to the fact
that it is an OCTET STRING.  I don't like the use of BMPString for much of
anything.  The only worry that I have is this is not being used according to
the description as this is not "locally in applications".  I would interpret
this as not leaving the local machine.  

Jim

From: Brockhaus, Hendrik <[email-masked]> 
Sent: Wednesday, May 6, 2020 2:43 AM
To: LAMPS WG <[email-masked]>; Jim Schaad <[email-masked]>
Cc: [email-masked]
Subject: draft-ietf-lamps-cmp-updates section 3.8 using pkcs-9-at-localKeyId
containing a revocation passphrase hint

During IETF 107 we discussed whether to use pkcs-9-at-friendlyName or
pkcs-9-at-localKeyId as specified in RFC 2985 section 5.5 in envelopedData
to transport an identifier for the revocation passphrase.

@Jim, did you manage to take a look on this and do you have a different
opinion?

-- Hendrik

---

From: "Brockhaus, Hendrik" <[email-masked]>
Date: Fri, 8 May 2020 06:29:42 +0000

> Von: Spasm <[email-masked]> Im Auftrag von Jim Schaad
> Gesendet: Mittwoch, 6. Mai 2020 19:12
>
> I would generally prefer the use of pkcs-9-at-localKeyId due to the fact that it is an OCTET STRING.  
> I don't like the use of BMPString for much of anything.  The only worry that I have is this is not 
> being used according to the description as this is not "locally in applications".  I would interpret this 
> as not leaving the local machine.  

I see the issue. RFC2985  says:
   The localKeyId attribute type specifies an identifier for a
   particular key.  It is only to be used locally in applications.

I updated Appendix B of RFC4210 only for completeness of changing from EncryptedValue to 
EncryptedKey. Therefore I tried to reuse existing OIDs instead of defining new ones. Currently I see the 
best fit with localKeyId for transporting the identifier of the revocation passphrase and I regard the 
extension of the scope as minor. What do others think?

Would the use of localKeyId be acceptable despite the slide expansion of the scope?
Does anyone sees a better solution?
Or should I register an additional OID for this use case?

-- Hendrik

> > From: Brockhaus, Hendrik <mailto:[email-masked]> 
> > During IETF 107 we discussed whether to use pkcs-9-at-friendlyName or pkcs-9-at-localKeyId as 
> > specified in RFC 2985 section 5.5 in envelopedData to transport an identifier for the revocation 
> > passphrase.

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 May 2020 13:05:21 -0400

> Would the use of localKeyId be acceptable despite the slide expansion of the scope?

I just reread that part of RFC 2985, and the meaning of "local" is not scoped in any way.  Since we are talking about a subject sending a message to the CA or RA, I think we can consider that to be "local".

> Or should I register an additional OID for this use case?

Let's just use the OID that has already been assigned in RFC 2985.

Russ