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

[Michael Richardson <[e-mail]>]

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 there another way to express the same concept that would be understandable
to more people?

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

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

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

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

    >> 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 liked the notion that it's an empty content, but then... is an empty
content ever valid?

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

RFC8555 also precludes the RA from providing a signature.

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