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

[David von Oheimb <[e-mail]>]

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:

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

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
this one:

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

> 
> > On Apr 5, 2022, at 10:31 AM, David von Oheimb
> > <[e-mail]> wrote:
> > 
> > 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.
> > > 
> > > 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
> > > > <[e-mail]> wrote:
> > > > 
> > > > 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:
> > > > > 
> > > > > 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?
> > > > 
> > > > 
> > > > Yes - using the existing (Extensions or) Extension datatype does
> > > > make sense.
> > > > This is one of the two options I also describe above.
> > > > 
> > > > David
> > > >