Subject: [lamps] New Version Notification for draft-richardson-lamps-rfc7030-csrattrs-02.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 07 Mar 2022 14:37:48 -0500

Hi, we started off in October with great enthusiasm, and there was a long,
somewhat meandering private thread about how to do things.
I asked if we could please take the thread to the ML, but did not receive
permission for that.  Maybe emails went astray.

I think that the co-authors span about 15 time zones, so having a virtual
meeting also didn't really happen.   Maybe in April?

The -02 that is posted below has many of the suggestions, although there was
one chunk of text, removed at:
    https://github.com/mcr/lamps-rfc7030-csrattrs/commit/5bc0b93173c5fe733091d2f1cfc1b3c265e082a4

which I removed because I just couldn't really understand it, and therefore
defend it.    It might be that it's redundant with the text that follows it.

I have posted some slides, which are at:
  https://github.com/mcr/lamps-rfc7030-csrattrs/blob/main/presentations/ietf113-lamps-csrattrs.pdf
until the chairs approve them into the meeting materials.
Please take note of slide 3.

(And: I have a parallel WG: DANCE that I'd also like to be at on Friday
morning, opposite LAMPS, but probably have to ewe-toob that)

Fundamentally, the decision that the WG needs to make is whether to

a) somehow extend the existing sequence items to include things that
   have a value.
   In slide 4, I slightly renamed what was there before from type/values to
   extType/extAttribute.
   The key algorith, key curve example motivates this change.

   This is fundamentally extensible to any thing one has an OID for.
   (slide 4)

b) create a new structure that has slots of the things we know we need,
   and can accomodate the extType/extAttributes of before.

   This is not more extensible than RFC7030 as presented, but could
   be pragmatic.
   (slide 5)

A new version of I-D, draft-richardson-lamps-rfc7030-csrattrs-02.txt
has been successfully submitted by Michael Richardson and posted to the
IETF repository.

Name:		draft-richardson-lamps-rfc7030-csrattrs
Revision:	02
Title:		Clarification of RFC7030 CSR Attributes definition
Document date:	2022-03-07
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/archive/id/draft-richardson-lamps-rfc7030-csrattrs-02.txt
Status:         https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030-csrattrs/
Html:           https://www.ietf.org/archive/id/draft-richardson-lamps-rfc7030-csrattrs-02.html
Htmlized:       https://datatracker.ietf.org/doc/html/draft-richardson-lamps-rfc7030-csrattrs
Diff:           https://www.ietf.org/rfcdiff?url2=draft-richardson-lamps-rfc7030-csrattrs-02

Abstract:
   Enrollment over Secure Transport (EST) is ambiguous in specification
   of the CSR Attributes Response.  This has resulted in implementation
   challenges and implementor confusion.  This document updates EST and
   clarifies how the CSR Attributes Response can be used by an EST
   server to specify both CSR attribute OIDs and also CSR attribute
   values that the server expects the client to include in its CSR
   request.

The IETF Secretariat

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Tue, 8 Mar 2022 13:55:14 +0000

[ofriel] If we could get the ASN right, then (a) is my preference as it is extensible and wouldn’t require a new draft revision to add a new attribute to the CSR. However, I am not too hung up on this and as Michael says (b) may be more pragmatic and it meets our immediate use case needs for subjectAltName.

---

From: David von Oheimb <[email-masked]>
Date: Wed, 09 Mar 2022 18:48:13 +0100

Hi Michael et al.,

> somewhat meandering private thread about how to do things.

good that you brought up this open CSRattrs topic again.

> permission for that.  Maybe emails went astray.

I lost overview of the various emails exchanged last autumn.
Anyway, fine by me to take the further discussion to the ML.

I may have mentioned already at some point that meanwhile I was told 
better not to use my private address [email-masked] (though I do not
really
have Siemens funding to work on it). So please replace it everywhere by 
[email-masked], also on the slide set and in the draft
document.

> meeting also didn't really happen.   Maybe in April?

I entered my dates in the Doodle poll
(though as mentioned the time I can spend on the topic is very limited).

> https://github.com/mcr/lamps-rfc7030-csrattrs/commit/5bc0b93173c5fe733091d2f1cfc1b3c265e082a4

Doing so, removing option one,
the numbering of the remaining options two, three and four need to be
updated.

> defend it.    It might be that it's redundant with the text that

It's not redundant, but just covers the case of subject name components,
in a way that does not work properly as I commented, so fine by me to
remove it.

> until the chairs approve them into the meeting materials.

Please correct the spelling of my last name on the title slide.

> Please take note of slide 3.

😂️

>    This is fundamentally extensible to any thing one has an OID for.

This slide appears to somehow cover "option two" (which is the 1st
remaining option).

This option is extremely hard to understand - not only because
description is missing,
but also because the encoding is very indirect using some difficult
generic types.
Still it appears not to allow specifying subject DNs,
and it appears wrong and redundant to me that each Value has three
components.

It should be explicitly described how to encode each aspect of a CSR
spec potentially needed:

* the requirement to use a challengePassword
* arbitrary X.509 extensions, optionally including required values
* a subject DN or part of it, if supported after all by this option
* an asymmetric key type, including any needed parameters
* a hash algorithm, including any needed parameters

as I did for the other two remaining options, where this anyway is much
more straightforward.

>    This is not more extensible than RFC7030 as presented, but could

This slide covers "option three" (which is the 2nd remaining
option), except that 
Name has been replaced by GenericName - can you remind us why this
(minor) change?

The 3rd remaining option ("option four") is not covered by the slide set
- why?

Regards,
 David

> URL:           
> https://www.ietf.org/archive/id/draft-richardson-lamps-rfc7030-csrattrs-02.txt
> Status:        
> https://datatracker.ietf.org/doc/draft-richardson-lamps-rfc7030-csrattrs/
> Html:          
> https://www.ietf.org/archive/id/draft-richardson-lamps-rfc7030-csrattrs-02.html
> Htmlized:      
> https://datatracker.ietf.org/doc/html/draft-richardson-lamps-rfc7030-csrattrs
> Diff:          
> https://www.ietf.org/rfcdiff?url2=draft-richardson-lamps-rfc7030-csrattrs-02
> 
> Abstract:

---

From: Sean Turner <[email-masked]>
Date: Fri, 25 Mar 2022 07:35:09 -0400

Sorry if I wasn’t clearer before about a “fix”. I think the examples in RFC 7030 could be fixed and maybe make it clear that you either send the “oid” if the server is saying hey send me a request with a value that you (the client) supply or “attribute” if the server is saying he send me a request with a value that I (the server) supply. Right now, RFC 7030 s4.5.2 includes an ASN.1 blob for the following examples:

       OID:        challengePassword (1.2.840.113549.1.9.7)

         Attribute:  type = extensionRequest (1.2.840.113549.1.9.14)
                     value = macAddress (1.3.6.1.1.1.1.22)

         Attribute:  type = id-ecPublicKey (1.2.840.10045.2.1)
                     value = secp384r1 (1.3.132.0.34)

         OID:        ecdsaWithSHA384 (1.2.840.10045.4.3.3)

We can expand the examples to:

1. Include a challengePassword with a value (caveats included about making sure it is protected when in transit) using the Attribute option.

2. Modify the extensionRequest example to include the right attribute value:

ExtensionRequest ::= Extensions

Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension

   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
                    -- contains the DER encoding of an ASN.1 value
                    -- corresponding to the extension type identified
                    -- by extnID
        }

Where:

extnID: 1.3.6.1.1.1.1.22
critical: FALSE and not encoded.
extnValue’s OCTET STRING is an IA5String.

This making sense?

spt

> On Mar 7, 2022, at 14:37, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
>

---

From: Dan Harkins <[email-masked]>
Date: Sun, 27 Mar 2022 08:48:18 -0700

Hi Sean,

   As long as we don't make existing, deployed EST code non-compliant I
think this is a good fix. There are implementations that abide by the
s4.5.2 description:

   "Requests to use a particular signature scheme (e.g. using a
    particular hash function) are represented as an OID to be reflected
    in the SignatureAlgorithm of the CSR.  Requests to use a particular
    crypto system (e.g., certification of a public key based on a certain
    elliptic curve) are represented as an attribute, to be reflected as
    the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type
    indicating the algorithm and the values indicating the particular
    parameters specific to the algorithm.  Requests for descriptive
    information from the client are made by an attribute, to be
    represented as Attributes of the CSR, with a type indicating the
    [RFC2985] extensionRequest and the values indicating the particular
    attributes desired to be included in the resulting certificate's
    extensions."

It's that last sentence that I think we're tweaking. CSRAttrs is being
used to request descriptive information from the client/EE that the
server/RA could not possibly know-- e.g. "what's your serial number?"--
and the value indicates the attribute the server/RA desires to be
included by the client/EE, not what that will end up being.

   So would the base64-encoded ASN.1 in s4.5.2, namely:

MEEGCSqGSIb3DQEJBzASBgcqhkjOPQIBMQcGBSuBBAAiMBYGCSqGSIb3DQEJDjEJ
     BgcrBgEBAQEWBggqhkjOPQQDAw==

be "legal" under your proposed rule? Pardon my ASN.1 ignorance.

   As an aside, why can't the RA just rewrite the CSR and include the
particular name it wants to impose on the EE? Yes, signature will be
wrong but the CA shouldn't care because the RA is vouching for it.
Right? Why won't that also fix this problem?

   regards,

   Dan.

-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Mar 2022 12:13:45 -0400

Sean Turner <[email-masked]> wrote:
    > Sorry if I wasn’t clearer before about a “fix”. I think the examples in
    > RFC 7030 could be fixed and maybe make it clear that you either send
    > the “oid” if the server is saying hey send me a request with a value
    > that you (the client) supply or “attribute” if the server is saying he
    > send me a request with a value that I (the server) supply.

Hi Sean,
Thank for speaking up last week.

I'm admit that I'm a bit lost as to what you are saying as it applies to the
document.   There were three possible situations before:
  a) the ASN.1 is all correct and values are supported by that ASN.1. Fix the example/text.
  b) the ASN.1 was incorrect and values were always intended to be supported.
     Fix the ASN.1
  c) values were never intended to be supported, nothing to "fix"
     Do a new protocol.

I thought we had concluded on (b), but in the meeting last week, what I heard
was (a) from you.

We agree that the examples do not motivate the second part ("value that server supplies").
I'm unclear if you are also saying that the ASN.1 is fine.

    > 2. Modify the extensionRequest example to include the right attribute

Are you saying that there are changes to the ASN.1 needed?

} ExtensionRequest ::= Extensions
}
} Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension
}
} Extension  ::=  SEQUENCE  {
}        extnID      OBJECT IDENTIFIER,
}        critical    BOOLEAN DEFAULT FALSE,
}        extnValue   OCTET STRING
}                    -- contains the DER encoding of an ASN.1 value
}                    -- corresponding to the extension type identified
}                    -- by extnID
}        }

This seems to be new ASN.1 which would replace CsrAttrs, AttrOrOid and Attribute?
I'm not sure I understand critical.

In the original examples, we had:

which is an extensionRequest for the macAddress extension, which the client
will fill in with it's macAddress.  (The MAC address to be used is not provided)

Dan asks that the result be upwards compatible with what was there before, but I
can't see how your proposal above accomplishes that.
I prefer to be upwards compatible, but I'm not as attached to that as Dan is.
(In particular, I don't mind creating a new /csrvalues request or some such,
as can then also fix the base64 stupid which we noted in the previous
clarifications document)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Tue, 29 Mar 2022 12:15:26 -0400

> Right? Why won't that also fix this problem?

It doesn't work for all RA/CA connections.
In particular, it won't work if the connection is ACME/RFC8555.
But, for some situations that certainly *will* work.

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 Mar 2022 13:31:17 -0400

hi Dan,

> On Mar 27, 2022, at 11:48, Dan Harkins <[email-masked]> wrote:
> 
> 
>   Hi Sean,
> 
> think this is a good fix.

I am definitely NOT out to make existing deployments non-compliant. I think could do that with some words like we handle the NULL AlgorithmParameters:

NOTE: There are two possible encodings for xxx because of an interpretation ...

> There are implementations that abide by the
> s4.5.2 description:
> 

So that base64 blob turns into the following (this is not actual ASN.1. I trimmed SEQUENCE -> SEQ, OBJECT IDENTIFIER -> OID, etc. to make it prettier)

SEQ (4 elem)
  OID 1.2.840.113549.1.9.7 challengePassword (PKCS #9)
  SEQ (2 elem)
    OID 1.2.840.10045.2.1 ecPublicKey (ANSI X9.62 public key type)
    SEQ OF (1 elem)
      OID 1.3.132.0.34 secp384r1 (SECG (Certicom) named elliptic curve)
  SEQ (2 elem)
    OID 1.2.840.113549.1.9.14 extensionRequest (PKCS #9 via CRMF)
    SEQ OF (1 elem)
      OID 1.3.6.1.1.1.1.22
  OID 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62 ECDSA algorithm with SHA384)

What I am saying is either:

a) The PKCS #9 via CRMF extensionRequest attribute should have had a properly encoded attribute when it was sent to the client. I mean strictly speaking the extensionRequest does include a type/value where type=extensionRequest and value=OID for macAdddress. BUT, the macAddress attribute also has a type/value that should have been included. This is how the attribute is defined (loosely):

        ( nisSchema.1.22 NAME 'macAddress'
          DESC 'MAC address in maximal, colon separated hex
                notation, eg. 00:00:92:90:ee:e2'
          EQUALITY caseIgnoreIA5Match
          SYNTAX 'IA5String{128}' )

We really shouldn’t have just dropped the value part of the attribute/extension carried in extensionRequest.  We could have said set the macAddress to “00" and then the client could include their actual mac address. But alas, we didn’t.

b) We picked the wrong kind attribute to request macAddress from the client. I cannot remember if it’s supposed to be naming component or an actual extension?

> Right? Why won't that also fix this problem?

In most instances, the RA could amend the CSR by adding/changing values. The CA would trust a valid sig from the RA to vouch for the changes.

Cheers,
spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 Mar 2022 13:47:48 -0400

hi!

> On Mar 29, 2022, at 12:13, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

I think the ASN.1 that’s there is right, but the example is wrong.

I also thought I heard you say that some people interpreted the text differently so we actually have to fix that too.

> Are you saying that there are changes to the ASN.1 needed?

No.

> I'm not sure I understand critical.

No. The above is the expansion of the extensionRequest. Right now the example stops short of including the extnValue.

> as can then also fix the base64 stupid which we noted in the previous

ack

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 29 Mar 2022 13:56:17 -0400

> On Mar 29, 2022, at 13:47, Sean Turner <[email-masked]> wrote:
> 
> hi!
> 

I guess I could have also said this:

>> }                    -- corresponding to the extension type identified

This value is needed because that’s how extensionRequest is defined (see RFC 2985).

In other words, the SET would include the OID and a value that is a value for an encoding of extensionRequest that includes SEQ OF SEQ {cid macAddress, extnValue OCTET STRING (some value)}.

This assumes that macAddress was meant to be an extension instead of a naming attribute. If it’s a naming attribute, then it’s the wrong attribute entirely in the example.

spt