Subject: Re: [lamps] is the CSRattr ASN.1 broken or not ... Re: New Version Notification for draft-richardson-lamps-rfc7030-csrattrs-02.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Apr 2022 14:24:14 -0400

Sean Turner <[email-masked]> wrote:
    >>> 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 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.

Would it be easier if we used the otherName example from RFC8994?
I'll dig that details out of my repo and post later today.
The doodle poll is complete, and I've set the meeting for Wed. April 6.

--
]               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: David von Oheimb <[email-masked]>
Date: Tue, 5 Apr 2022 14:30:49 +0200

As I wrote earlier, the way CSRattrs are defined for EST in RFC
7030 section 4.5.2:

CsrAttrs ::= SEQUENCE SIZE (0..MAX) OF AttrOrOID

AttrOrOID ::= CHOICE (oid OBJECT IDENTIFIER, attribute Attribute }

Attribute { ATTRIBUTE:IOSet } ::= SEQUENCE {
type ATTRIBUTE.&id({IOSet}),
values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

is 

* pretty incomprehensible, at least for ASN.1 non-experts
* very ambiguous: how to interpret bare OIDs and attribute type OIDs
that the server my throw in is not really defined, apart from a few
hints and examples,
  and it is left entirely open which values are allowed for which
attribute type OIDs
* not fully expressive: at least subject DNs (or parts of them) cannot
be specified

Moreover, as recently discussed here again, the example given in RFC
7030 for the macAddress extension was pretty unfortunate in the sense
that
it seemed to preclude the case that an actual extension value is given
by the server, while I agree with Sean that the above weird ASN.1 syntax
should allow for that.

On Tue, 2022-03-29 at 13:31 -0400, Sean Turner wrote:
> 
> 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.

The question is which kind of values (of type
ATTRIBUTE.&Type({IOSet}{@type}) ) should be given
in case the OID  (of type  ATTRIBUTE.&id({IOSet})) is
1.2.840.113549.1.9.14 extensionRequest:
Is each such value supposed to be 
1. an OID of an X.509 extension, such as 1.3.6.1.1.1.1.22 (macAddress),
without a value, or
2. an actual X.509 extension of the existing type Extension (or
Extensions) as defined in RFC 5280 section 4.1,
    for example the OID 1.3.6.1.1.1.1.22 followed by the 'critical' flag
and its actual value encoded as an OCTET STRING

Note that for syntactic and semantics reasons you cannot have both -
either 
1. the example given in RFC 7030 was correct, then no X.509 extension
value can be given by the server, or
2. the example was wrong, and a value must be given by the server. 
    Yet the OCTET STRING could be the empty string to indicate that the
client should fill in the real value.
    The Lightweight CMP Profile also employs this trick of using an
empty extnValue
    in its section 4.3.3. (Get certificate request template):
 
  https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3

The latter option is obviously more expressive, but note that this
contradicts the example of RFC 7030, 
and thus chances are high that (most) existing EST implementations chose
the first option, which is not compatible with the second.

> 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?

Apart from the two possibilities I just gave, I do not see how else,
given given the CsrAttrs syntax, 
one should have requested a macAddress X.509 extension where the value
is to be filled by the client.

> 
> >   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?
> 
> 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.

As I commented earlier,
PKCS#10 requires a self-signature within the CSR structure, which that
RA cannot provide, so there are basically two options:
* cheat and give a bogus signature to be ignored by the CA, or 
* switch to a more expressive CSR syntax like CRMF, which supports
popo=raVerified
   (i.e., the RA vouches for having checked the original proof of
possession by the client and does not provide a new one) 

On Fri, 2022-03-25 at 07:35 -0400, Sean Turner 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.
> 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.

It would make little sense for the server to provide a challengePassword
value - this is to be given by the client in order to authenticate
itself.

> 2. Modify the extensionRequest example to include the right attribute
> value:
> 
> 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?

Yes - using the existing (Extensions or) Extension datatype does make
sense.
This is one of the two options I also describe above.

 David

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2022 10:00:11 -0400

I would like to up-level this discussion.  Since the CrsAttrs is flexible enough that more than one way to use it has been described for the very same CSR information, I suspect that what we need is to specify conventions for the CSR information that people are actually using.  And, we can add more in the future if needed.

Looking to RFC 7030, there are several cases that are discussed in Section 4.5.2:

- the CA requires a particular crypto system

- the CA requires use of a particular signature scheme

- the EST server requires the linking of identity

- the EST server requires POP information

And, for some of the above, it includes guidance:

-  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

So, can we list various CSR information that people actually use or want to use, and then specify conventions for each one.

The convention should say what the EST server puts in this structure, and the expected result in the CSR if the EST client understands that OID.

Russ

> On Apr 5, 2022, at 8:30 AM, David von Oheimb <[email-masked]> wrote:
> 
> As I wrote earlier, the way CSRattrs are defined for EST in RFC 7030 section 4.5.2: 
> 
>         values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type <mailto:{IOSet}{@type>}) }
> 
> is 
> 
> * very ambiguous: how to interpret bare OIDs and attribute type OIDs that the server my throw in is not really defined, apart from a few hints and examples,
>   and it is left entirely open which values are allowed for which attribute type OIDs
> * not fully expressive: at least subject DNs (or parts of them) cannot be specified
> 
> Moreover, as recently discussed here again, the example given in RFC 7030 for the macAddress extension was pretty unfortunate in the sense that
> it seemed to preclude the case that an actual extension value is given by the server, while I agree with Sean that the above weird ASN.1 syntax should allow for that.
> 
> 
>> 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.3.132.0.34 secp384r1 (SECG (Certicom) named elliptic curve)
>>   SEQ (2 elem)
>>   OID 1.2.840.10045.4.3.3 ecdsaWithSHA384 (ANSI X9.62 ECDSA algorithm with SHA384)
>> 
>> 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):
>> 
>> 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.
> 
> The question is which kind of values (of type ATTRIBUTE.&Type({IOSet}{@type <mailto:{IOSet}{@type>}) ) should be given
> in case the OID  (of type  ATTRIBUTE.&id({IOSet})) is 1.2.840.113549.1.9.14 extensionRequest:
> 1. an OID of an X.509 extension, such as 1.3.6.1.1.1.1.22 (macAddress), without a value, or
> 2. an actual X.509 extension of the existing type Extension (or Extensions) as defined in RFC 5280 section 4.1,
>     for example the OID 1.3.6.1.1.1.1.22 followed by the 'critical' flag and its actual value encoded as an OCTET STRING
> 
> Note that for syntactic and semantics reasons you cannot have both - either 
> 1. the example given in RFC 7030 was correct, then no X.509 extension value can be given by the server, or
>     Yet the OCTET STRING could be the empty string to indicate that the client should fill in the real value.
>     The Lightweight CMP Profile also employs this trick of using an empty extnValue
>     https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3 <https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-4.3.3>
> 
> The latter option is obviously more expressive, but note that this contradicts the example of RFC 7030, 
> and thus chances are high that (most) existing EST implementations chose the first option, which is not compatible with the second.
> 
> 
>> 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?
> 
> Apart from the two possibilities I just gave, I do not see how else, given given the CsrAttrs syntax, 
> one should have requested a macAddress X.509 extension where the value is to be filled by the client.
> 
> 
>> 
>> 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.
> 
> As I commented earlier,
> PKCS#10 requires a self-signature within the CSR structure, which that RA cannot provide, so there are basically two options:
> * switch to a more expressive CSR syntax like CRMF, which supports popo=raVerified
>    (i.e., the RA vouches for having checked the original proof of possession by the client and does not provide a new one) 
> 
> 
>> 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:
>> 
>> 1. Include a challengePassword with a value (caveats included about making sure it is protected when in transit) using the Attribute option.
> 
> It would make little sense for the server to provide a challengePassword value - this is to be given by the client in order to authenticate itself.
> 
> 
>> 2. Modify the extensionRequest example to include the right attribute value:
>> 
> Yes - using the existing (Extensions or) Extension datatype does make sense.
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: David von Oheimb <[email-masked]>
Date: Tue, 5 Apr 2022 16:31:17 +0200

The problem space is a little more tricky:

* Backward compatibility is an important aim.

  In case it turns out that compatibility anyway needs to be abandoned,
  I'd suggest the following straightforward fully to-the-point type,
  which does not require any (direct) OIDs:

   CsrAttrs ::= SEQUENCE {
        subject               Name OPTIONAL,
        extensions            SEQUENCE OF Extension, /* use empty extnValue for those extensions to be filled in by client */
        challengePassword     BOOLEAN,
        keySpec           [0] KeySpec OPTIONAL,
        hashAlg           [1] AlgorithmIdentifier OPTIONAL

   }

* The ambiguity between the server specifying required X.509 extension
OIDs or actual X.509 extension values needs to be sorted out, on a per-
extension basis.
   That is, it should be made possible to specify a set of extensions to
be included in the CSR, where for each of them the server may provide
the value or not.

 David

On Tue, 2022-04-05 at 10:00 -0400, Russ Housley wrote:
> I would like to up-level this discussion.  Since the CrsAttrs is
> flexible enough that more than one way to use it has been described
> for the very same CSR information, I suspect that what we need is to
> specify conventions for the CSR information that people are actually
> using.  And, we can add more in the future if needed.
> 
> So, can we list various CSR information that people actually use or
> want to use, and then specify conventions for each one.
> 
> The convention should say what the EST server puts in this structure,
> and the expected result in the CSR if the EST client understands that
> OID.
> 
> Russ
> 
> 
> > 7030 for the macAddress extension was pretty unfortunate in the
> > sense that
> > it seemed to preclude the case that an actual extension value is
> > given by the server, while I agree with Sean that the above weird
> > ASN.1 syntax should allow for that.
> > 
> > 
> > > ASN.1. I trimmed SEQUENCE -> SEQ, OBJECT IDENTIFIER -> OID, etc.
> > > to make it prettier)
> > > 
> > > SEQ (4 elem)
> > > 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):
> > > 
> > > 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.
> > 
> > 
> >     for example the OID 1.3.6.1.1.1.1.22 followed by the 'critical'
> > flag and its actual value encoded as an OCTET STRING
> > 
> > 1. the example given in RFC 7030 was correct, then no X.509
> > extension value can be given by the server, or
> >     Yet the OCTET STRING could be the empty string to indicate that
> > the client should fill in the real value.
> > and thus chances are high that (most) existing EST implementations
> > chose the first option, which is not compatible with the second.
> > 
> > 
> > > 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?
> > 
> > 
> > > values. The CA would trust a valid sig from the RA to vouch for
> > > the changes.
> > 
> > 
> > As I commented earlier,
> > PKCS#10 requires a self-signature within the CSR structure, which
> > that RA cannot provide, so there are basically two options:
> > > 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:
> > > 
> > > 1. Include a challengePassword with a value (caveats included
> > > about making sure it is protected when in transit) using the
> > > Attribute option.
> > 
> > 
> > It would make little sense for the server to provide a
> > challengePassword value - this is to be given by the client in order
> > to authenticate itself.
> > 
> >

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2022 11:57:37 -0400

I do not understand why my approach leads to a backward compatibility concern.  Only if the same OID is being used in more than one way by different implementations is there a concern.  If we can list those, we might be able to just document the preferred approach and note the other things that are seen in the wild.

Russ

> On Apr 5, 2022, at 10:31 AM, David von Oheimb <[email-masked]> wrote:
> 
> * The ambiguity between the server specifying required X.509 extension OIDs or actual X.509 extension values needs to be sorted out, on a per-extension basis.
>    That is, it should be made possible to specify a set of extensions to be included in the CSR, where for each of them the server may provide the value or not.
> 
> 	David
> 
>>> On Apr 5, 2022, at 8:30 AM, David von Oheimb <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: David von Oheimb <[email-masked]>
Date: Tue, 5 Apr 2022 18:47:06 +0200

On Tue, 2022-04-05 at 11:57 -0400, Russ Housley wrote:

> I do not understand why my approach leads to a backward compatibility
> concern.

The problem hides in the part

> the values indicating the particular attributes desired to be included
> in the resulting certificate's extensions

and essentially is the same issue I also addressed earlier today:

> >     [...]

I agree with:

> Only if the same OID is being used in more than one way by different
> implementations is there a concern.
> If we can list those, we might be able to just document the preferred
> approach and note the other things that are seen in the wild.

Yet as I wrote, I fear there are EST implementations that take the value
of each extensionRequest Attribute simply as an OID with no value
provided by the server,
which is not compatible with the goal of being able to express for each
extensionRequest Attribute, where needed, an actual X.509 extension with
a value provided by the server
(each being a structure having an OID, the criticality flag, and the
encoded value).

I also agree with most of the points you wrote earlier today, except for

> - the EST server requires POP information

There is no need for the server to specify this, simply because the
PKCS#10 structure to be sent by the client anyway needs to be self-
signed, yielding the POP.

 David

> > * The ambiguity between the server specifying required X.509
> > extension OIDs or actual X.509 extension values needs to be sorted
> > out, on a per-extension basis.
> >    That is, it should be made possible to specify a set of
> > extensions to be included in the CSR, where for each of them the
> > server may provide the value or not.
> > 
> > David
> > 
> > > flexible enough that more than one way to use it has been
> > > described for the very same CSR information, I suspect that what
> > > we need is to specify conventions for the CSR information that
> > > people are actually using.  And, we can add more in the future if
> > > needed.
> > > 
> > > So, can we list various CSR information that people actually use
> > > or want to use, and then specify conventions for each one.
> > > 
> > > The convention should say what the EST server puts in this
> > > structure, and the expected result in the CSR if the EST client
> > > understands that OID.
> > > 
> > > Russ
> > > 
> > > 
> > > > * very ambiguous: how to interpret bare OIDs and attribute type
> > > > OIDs that the server my throw in is not really defined, apart
> > > > from a few hints and examples,
> > > > Moreover, as recently discussed here again, the example given in
> > > > RFC 7030 for the macAddress extension was pretty unfortunate in
> > > > the sense that
> > > > given by the server, while I agree with Sean that the above
> > > > weird ASN.1 syntax should allow for that.
> > > > 
> > > > 
> > > > > 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)
> > > > > 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):
> > > > > 
> > > > > 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.
> > > > 
> > > > 
> > > >     for example the OID 1.3.6.1.1.1.1.22 followed by the
> > > > 'critical' flag and its actual value encoded as an OCTET STRING
> > > > 
> > > >     Yet the OCTET STRING could be the empty string to indicate
> > > > that the client should fill in the real value.
> > > > The latter option is obviously more expressive, but note that
> > > > this contradicts the example of RFC 7030, 
> > > > and thus chances are high that (most) existing EST
> > > > implementations chose the first option, which is not compatible
> > > > with the second.
> > > > 
> > > > 
> > > > > 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?
> > > > 
> > > > 
> > > > > 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.
> > > > 
> > > > 
> > > > As I commented earlier,
> > > > PKCS#10 requires a self-signature within the CSR structure,
> > > > which that RA cannot provide, so there are basically two
> > > > options:
> > > >    (i.e., the RA vouches for having checked the original proof
> > > > of possession by the client and does not provide a new one) 
> > > > 
> > > > 
> > > > > 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:
> > > > > 
> > > > challengePassword value - this is to be given by the client in
> > > > order to authenticate itself.
> > > > 
> > > >

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Apr 2022 13:39:28 -0400

> I do not understand why my approach leads to a backward compatibility

I'm not sure that your proposal does.
I think that David is just posting a strawman for the case where we think we
can't make it work.

    > Only if the same OID is being used in more than one way by
    > different implementations is there a concern.  If we can list those, we
    > might be able to just document the preferred approach and note the
    > other things that are seen in the wild.

The only question for me is clarifying what it means to request a value.

>>    the AlgorithmIdentifier of the SubjectPublicKeyInfo, with a type

is a case where the Registrar/EST-server is telling the client to use a
particular value for the AlgorithmIdentifier.  Yes, that has knock-on effects
in making it pick a particular public key format!

But, it feels the same as the Registrar/EST-server telling the client what
dNSName to put into the SAN.

(Russ: I added you to the invite to the design team meeting tomorrow. Come if
you have time)

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 05 Apr 2022 14:18:59 -0400

> values SET SIZE(1..MAX) OF ATTRIBUTE.&Type({IOSet}{@type}) }

Is there another way to express the same concept that would be understandable
to more people?

    >     in its section 4.3.3. (Get certificate request template):

Sean has pushed us in the direction of (2).
This is in contrast to what happened last August!

    > the first option, which is not compatible with the second.

I think that the tree-in-forest question applies.
If those implementations never had to deal with specific values, and continue
to avoid doing that, then they won't encounter a problem :-)

    > is to be filled by the client.

It's a good question.
I liked the notion that it's an empty content, but then... is an empty
content ever valid?

    > possession by the client and does not provide a new one) 

RFC8555 also precludes the RA from providing a signature.

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2022 14:33:23 -0400

> On Apr 5, 2022, at 12:47 PM, David von Oheimb <[email-masked]> wrote:
> 
>> I do not understand why my approach leads to a backward compatibility concern.
> 
>> the values indicating the particular attributes desired to be included in the resulting certificate's extensions
> 
>> Only if the same OID is being used in more than one way by different implementations is there a concern.
>> If we can list those, we might be able to just document the preferred approach and note the other things that are seen in the wild.
> 
> Yet as I wrote, I fear there are EST implementations that take the value of each extensionRequest Attribute simply as an OID with no value provided by the server,
> which is not compatible with the goal of being able to express for each extensionRequest Attribute, where needed, an actual X.509 extension with a value provided by the server
> (each being a structure having an OID, the criticality flag, and the encoded value).

I understand this point, but there are cases where the EST server does not need to provide a value.  I'm hoping that wehen we really see what everyone is actually doing, the gap will not be as bad as the imagined possibilities.

Russ

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2022 14:40:02 -0400

> On Apr 5, 2022, at 2:18 PM, Michael Richardson <[email-masked]> wrote:
> 
> David von Oheimb <[email-masked] <mailto:[email-masked]>> wrote:

I do not know whether the OLD ASN.1 syntax is easier to read for some.  This would be:

   Attribute ::= SEQUENCE {
     type     AttributeType,
     values    SET SIZE(1..MAX) OF AttributeValue }

   AttributeType ::= OBJECT IDENTIFIER

   AttributeValue ::= ANY DEFINED BY AttributeType

Russ

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Tue, 5 Apr 2022 18:46:26 +0000

I do not know whether the OLD ASN.1 syntax is easier to read for some.  

Far easier. Trivially easy. 

Note, that I’ve been dealing with ASN.1 since early 1990-ties, and maintain a fork of asn1c compiler. Which, mind you, won’t grok the “new” ASN.1.

This would be:

   Attribute ::= SEQUENCE {

     type     AttributeType,

---

From: Sean Turner <[email-masked]>
Date: Tue, 5 Apr 2022 15:26:53 -0400

> On Apr 5, 2022, at 11:57, Russ Housley <[email-masked]> wrote:
> 

I know there are folks that would like to provide the client the entire CSR, minus the public key & signature on the CSR. You can do that by returning a pKCS7PDU attribute with a ContentInfo of PKIData->reqSequence->tcr/crm. If the client and server have some kind of trust relationship, then the server could also sign the PKIData.

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 5 Apr 2022 15:28:16 -0400

> On Apr 5, 2022, at 14:40, Russ Housley <[email-masked]> wrote:
> 
> 
> 

The problem really comes down to how extensionRequest is encoded. extensionRequest is defined in RFC 2985) as:

   extensionRequest ATTRIBUTE ::= {
           WITH SYNTAX ExtensionRequest
           SINGLE VALUE TRUE
           ID pkcs-9-at-extensionRequest
   }

Then Extensions (using old syntax from 5280):

   Extension  ::=  SEQUENCE  {

So, if you’re going to encode that you need a lot more than just an OID, as is in the example:

In the example:

SEQUENCE (4 elem)
… snip
  SEQUENCE (2 elem)
    OBJECT IDENTIFIER 1.2.840.113549.1.9.14 extensionRequest (PKCS #9 via CRMF)
    SET (1 elem)
      OBJECT IDENTIFIER 1.3.6.1.1.1.1.22 (macAddress). <—“values" here
..snip

If macAddress is included as an extension, then it would need to say whether it’s critical or not and we’d need to provide a value. The “values” portion of the SET OF needs to be:
SEQ OF (for Extensions)
  SEQ (for Extension)
   { extrnID=macAddress OID,
    criticality=T/F (CP dependent),
    extnValue=? } 

I just want to double check again that the macAddress attribute is being carried in the certificate as an actual extension and NOT as a naming attribute?

Cheers,
spt

---

From: Russ Housley <[email-masked]>
Date: Tue, 5 Apr 2022 15:50:24 -0400

> On Apr 5, 2022, at 3:28 PM, Sean Turner <[email-masked]> wrote:
> 
> 
> 

RFC 7030 shows this example:

  0  65: SEQUENCE {
  2   9:   OBJECT IDENTIFIER challengePassword (1 2 840 113549 1 9 7)
 13  18:   SEQUENCE {
 15   7:     OBJECT IDENTIFIER ecPublicKey (1 2 840 10045 2 1)
 24   7:     SET {
 26   5:       OBJECT IDENTIFIER secp384r1 (1 3 132 0 34)
       :       }
       :     }
 33  22:   SEQUENCE {
 35   9:     OBJECT IDENTIFIER extensionRequest (1 2 840 113549 1 9 14)
 46   9:     SET {
 48   7:       OBJECT IDENTIFIER '1 3 6 1 1 1 1 22'
       :       }
       :     }
 57   8:   OBJECT IDENTIFIER ecdsaWithSHA384 (1 2 840 10045 4 3 3)
       :   }

Maybe this is what you meant when you said that the example is wrong.  You mean that the example fails to include the ExtensionRequest as the values field in the attribute.

>    criticality=T/F (CP dependent),

The problem is that the EST server is saying that the CSR needs to include the extensionRequest attribute, and that the SEQUENCE OF Extension needs to include the macAddress extension.  The EST server expects the client to fill in the MAC address.  The EST server does not know the client's MAC address, so it cannot fill it in.  It could put a zero-length OCTET STRING, but that is not ideal.

Russ

---

From: David von Oheimb <[email-masked]>
Date: Wed, 6 Apr 2022 08:33:33 +0200

On Tue, 2022-04-05 at 14:18 -0400, Michael Richardson wrote:
> 
>     >> 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?
> 
>     > Apart from the two possibilities I just gave, I do not see how
> else,
>     > given given the CsrAttrs syntax,
>     > one should have requested a macAddress X.509 extension where the
> value
>     > is to be filled by the client.
> 
> It's a good question.

I'd say yes, in the following sense: 
It's syntactically valid, and semantically it makes clear that the
server did not provide a value, 
which conveys the requirement that the value shall be filled in by the
client.

Here is a new thought, an alternative way of giving in a clean way both
the option to provide X.509 extensions with values and others without
values:

Have two OIDs for attribute types requiring the inclusion of X.509
extensions,
* one (likely) being extensionRequest (1.2.840.113549.1.9.14) and
* a second one that likely needs to be newly defined.

One of these two OIDs would be followed by a structure of the existing
type Extension (which contains the actual extension value) to be
included in the CSR, 
and the other one would be followed just by an OID stating the type of
an X.509 extension to be included in the CSR, with the client filling in
its value.

Also this solution does not require changes to the CsrAttrs type
declaration given in RFC 7030.

 David