Subject: [Curdle] Comments on draft-ietf-curdle-pkix-04

From: Klaus Hartke <[email-masked]>
Date: Wed, 29 Mar 2017 16:47:57 +0200

A few comments/questions:

* OIDs for HashEdDSA.

I didn't follow the entire discussion, so this might have already been
brought up. I see two use cases outside the X.509 Public Key
Infrastructure where it might be useful to have OIDs for HashEdDSA:

- Using SubjectPublicKeyInfo as an interchange format for public keys.
RFC 7250 [1] does this, for example.

- Using SubjectPublicKeyInfo and OneAsymmetricKey as a storage format
for public and private keys.

I'm not sure how important the first case is, but I'm interested in
the second case: With the id-Ed25519ph OID gone, I now have to choose
between inventing my own storage format for Ed25519ph keys, using the
id-Ed25519 OID for both Ed25519 and Ed25519ph keys, or using the
id-Ed25519ph OID in the hope that it isn't allocated for something
else in the future.

* OneAsymmetricKey.

I think having only one way to encode a SubjectPublicKeyInfo is a very
good idea. In my implementation, I do not even have an ASN.1 parser
for SubjectPublicKeyInfos, because I can simply concatenate a
pre-computed prefix with the public key bytes, e.g.,

    0x30, 0x2A, 0x30, 0x05, 0x06, 0x03, 0x2B, 0x65,
    0x70, 0x03, 0x21, 0x00,

followed by the 32 bytes of an Ed25519 public key.

Could the same be done for OneAsymmetricKey? (version MUST be v1 and
both attributes and publicKey MUST NOT be present)

If not:

- Does anyone have test vectors for valid and invalid
OneAsymmetricKeys that include all possible encodings of all possible
combinations of optional items?

- Is it OK to simply ignore anything after privateKey or does an
implementation, e.g., have to check if publicKey is actually the
correct public key for privateKey?

* Small typo in section 7:

   encoded key as defined in [RFC7748] and [RFC8032].  public key.
                                                       ^^^^^^^^^^^

Klaus

[1] https://tools.ietf.org/html/rfc7250

---

From: Jim Schaad <[email-masked]>
Date: Wed, 29 Mar 2017 12:10:11 -0500

> -----Original Message-----
> From: Curdle [mailto:[email-masked]] On Behalf Of Klaus Hartke
> Sent: Wednesday, March 29, 2017 9:48 AM
> To: [email-masked]
> Subject: [Curdle] Comments on draft-ietf-curdle-pkix-04
> 
brought
> up. I see two use cases outside the X.509 Public Key Infrastructure where
it
> might be useful to have OIDs for HashEdDSA:
> 
> - Using SubjectPublicKeyInfo and OneAsymmetricKey as a storage format for
> public and private keys.
> 
> I'm not sure how important the first case is, but I'm interested in the
second
> case: With the id-Ed25519ph OID gone, I now have to choose between
> inventing my own storage format for Ed25519ph keys, using the
> id-Ed25519 OID for both Ed25519 and Ed25519ph keys, or using the id-
> Ed25519ph OID in the hope that it isn't allocated for something else in
the
> future.

The OID assignment does not really go away, we are just choosing not to
document them here.  It could be done as part of a separate document,
however the reasons that were discussed for not doing it in this document
should still be considered in terms of do you really need these algorithms.

> I think having only one way to encode a SubjectPublicKeyInfo is a very
good
> idea. In my implementation, I do not even have an ASN.1 parser for
> SubjectPublicKeyInfos, because I can simply concatenate a pre-computed
> prefix with the public key bytes, e.g.,
> 

This is going to be the normal situation.  However, there are some
circumstances where the additional fields are useful.

> 
> If not:
> 
> - Does anyone have test vectors for valid and invalid OneAsymmetricKeys
that
> include all possible encodings of all possible combinations of optional
items?

I don't know of any such thing - and an exhaustive set could not be created
as the attributes are themselves open ended.

> implementation, e.g., have to check if publicKey is actually the correct
public
> key for privateKey?

Normally, one will just ignore the public key and compute it oneself.  There
are some circumstances where devices need to have this field delivered.
Normally it can just be ignored.

>    encoded key as defined in [RFC7748] and [RFC8032].  public key.

Thanks - fixed.

Jim

> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle

---

From: Brian Smith <[email-masked]>
Date: Wed, 29 Mar 2017 09:49:48 -1000

Jim Schaad <[email-masked]> wrote:
> public key for privateKey?
>

FWIW, I do check that the private key and the public key are
consistent and I think it's a good idea unless you can't afford to
recompute the public key.

Cheers,
Brian
-- 
https://briansmith.org/