Re: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

[Mike Ounsworth <[e-mail]>]

> [CW] Sure. I don’t disagree one could omit the ignored stuff and arrive at the “pause work on an attestation statement and focus first on a CSR attr” point you referenced earlier but ignoring some parts doesn’t strike me as the way to go about it. If you ignore all the other bits you have a type and a bit bucket, which is what I was advocating for instead of this compound approach.

.. you know, at this rate, it would have saved everyone time if you’d just attended the meeting 👀

Yes, correct. 11/12 of us (ie the HSM and CA ppl) just want a type and bit bucket. MSJ wants to be able to unroll the structure to serve the TPM and WebAuthn use-cases. Fine. Tag them OPTIONAL so I can treat this as a {id, OCTET STRING} and then I don’t care.

---
Mike Ounsworth

From: Carl Wallace <[e-mail]>
Sent: Monday, May 22, 2023 2:16 PM
To: Mike Ounsworth <[e-mail]>; Michael StJohns <[e-mail]>; [e-mail]
Subject: [EXTERNAL] Re: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Inline…

From: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 22, 2023 at 2:57 PM
To: Carl Wallace <[e-mail]<mailto:[e-mail]>>, Michael StJohns <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

Hey! It’s like you were at the meeting today! We also spent 20 minutes on that point!


I don’t think it does; the salient bits are:

[CW] This thread has a distinct “these aren’t the droids you’re looking for” flavor.


attestAttribute ATTRIBUTE ::= {
        TYPE AttestStatement
        COUNTS MAX 1
        IDENTIFIED BY id-at-attestForCSR
    }




-- algId, signature are OPTIONAL to allow for opaque key attestation statements that already include the signature.

-- ancillaryData is to accommodate TPM / WebAuthn statements that wish to be "unrolled" rather than bundle itself into an opaque octet string.

AttestStatement { ATTEST-STATEMENT:IOSet}  ::= SEQUENCE

  {

    type          ATTEST-STATEMENT.&id({IOSet}),

    value         ATTEST-STATEMENT.&Type({IOSet}{@type}),

    algId         [0] IMPLICIT  AlgorithmIdentifier OPTIONAL,

    signature     [1] ATTEST-STATEMENT.&sigType OPTIONAL -- NOT implicit

    ancillaryData [2] IMPLICIT  OCTET STRING OPTIONAL

  }


From there, I am free to register id-at-keyattest-entrust with a Type OCTET STRING, ignore those optional values, and I’m off to the races for putting my proprietary blob into a CSR.
[CW] Sure. I don’t disagree one could omit the ignored stuff and arrive at the “pause work on an attestation statement and focus first on a CSR attr” point you referenced earlier but ignoring some parts doesn’t strike me as the way to go about it. If you ignore all the other bits you have a type and a bit bucket, which is what I was advocating for instead of this compound approach.

PS; @Michael StJohns<mailto:[e-mail]> – you have a “type” with type “id” and a “value” with type “Type”. I was expecting “type” to have type “Type”. We could probably de-confusingify that a bit.

---
Mike Ounsworth

From: Carl Wallace <[e-mail]<mailto:[e-mail]>>
Sent: Monday, May 22, 2023 1:42 PM
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Michael StJohns <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Ok, but that’s not pausing work on attestation statement to focus on CSR. That draft does both (and more).

From: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 22, 2023 at 2:30 PM
To: Carl Wallace <[e-mail]<mailto:[e-mail]>>, Michael StJohns <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

No changes proposed at this point. I think what MSJ wrote down is fine – overly verbose for the CA/B HSM -> CA need, but not in a way that interferes, so no objection.

---
Mike Ounsworth

From: Carl Wallace <[e-mail]<mailto:[e-mail]>>
Sent: Monday, May 22, 2023 1:09 PM
To: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>; Michael StJohns <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Great. I will be interested to see how the AttestAttribute and AttestStatement structures change (or if the latter just goes away). Thanks.

From: Mike Ounsworth <[e-mail]<mailto:[e-mail]>>
Date: Monday, May 22, 2023 at 2:05 PM
To: Carl Wallace <[e-mail]<mailto:[e-mail]>>, Michael StJohns <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

Carl,

Noted that the appropriate homes are:

CSR Attr --> LAMPS
Attestation Statement --> RATS.

We met today and I am in the process of writing up a meeting summary for the list, but the sneak-peek is that we decided to pause work on an attestation statement and focus first on a CSR attr so that things that can already do attestations can start sending them to CAs ASAP (for which draft-stjohns-csr-attest is the defacto working draft). When we get back to a general-purpose key attestation statement, I hear you that RATS will probably be the right place.

---
Mike Ounsworth

From: Spasm <[e-mail]<mailto:[e-mail]>> On Behalf Of Carl Wallace
Sent: Monday, May 22, 2023 12:57 PM
To: Michael StJohns <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] Re: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

WARNING: This email originated outside of Entrust.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Replies inline prefaced by [CW]…

From: Michael StJohns <[e-mail]<mailto:[e-mail]>>
Date: Thursday, May 18, 2023 at 4:25 PM
To: Carl Wallace <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt

On 5/18/2023 10:35 AM, Carl Wallace wrote:
I reviewed the draft. Below are some comments, questions and suggestions.

General

- Somewhere in this specification there should be a rule that governs the relationship between the public key that appears in the AttestAttribute and the public key that appears in the certificate request containing the AttestAttribute.

I'm of two minds on this.  If I've got a CSR with a bunch of attributes, I'm going to assume that the attributes apply in some manner to the CSR.  If I've got an attestation attribute, I'm going to assume that the attestation in some way applies to the key to be bound to a certificate.

But I guess that could be stated explicitly - but the idea here is that an attestAttribute might be used in things other than a PKCS10 CSR.  I don't know that I would characterize that as a rule per se.

[CW] If you don't check, what prevents substitution of a valid attestation for a different key?

Given that an attest statement may or may not contain the public key, a hash of the public key or some other pointer to the public key,  it may be more appropriate for the definition of a specific AttestationStatement to define what the mapping is between it and a given public key.

[CW] I've never seen a key attestation that does not contain a key. Do you have an example? If the goal is a general purpose attestation mechanism, then the work is probably better addressed in RATS.

- One complaint from some regarding draft-ietf-lamps-key-attestation-ext-00 was that it used CBOR. One alternative that has been discussed is to use an ASN.1 structure that contains a type value and a bit bucket. Why are the structures in this spec preferable to something simple like the below? You could even dispense with a wrapper structure like this and just define OIDs for various key attestation formats.

AttestationStatement ::= SEQUENCE {
                type OBJECT IDENTIFIER,
                statement OCTET STRING
}


I think I mentioned that the above is disfavored.  It's still used in things like the signature field and Extensions of an X.509 certificate because those definitions pre-date the deprecation of "ANY".   If you're wrapping non-ASN1 you stick it in an OCTET STRING.  If you're wrapping  ASN1 you do not encode the ASN1 and stick the bytes of that encoding in the body of an OCTET STRING, you place the object in the structure as-is.

[CW] The structure could be written using current ASN.1 syntax to tighten that up. Encoded ASN.1 appears in OCTET STRINGs all the time. Doing that here would make the whole concept much simpler (at the cost of a couple of bytes for tag and length).

WRT to CBOR etc - this is LAMPS so we're mostly talking about how to encode things for PKIX related items.  To the extent possible, at this level avoiding additional encoding regimes is highly desirable.

[CW] There is nothing about LAMPS that prohibits addressing CBOR. The horse has left the barn with regard to key attestation formats. Some are in CBOR and it'd be good to have a means of presenting those as evidence when requesting certificates. Defining an attestation or new certificate types seems to be on less solid ground charter-wise. Attestation statement work should likely be conducted in RATS (with CSR binding done in LAMPS). New certificate formats would likely be LAMPS but may need a charter mod.
Section 1

First paragraph

- I am assuming the two specifications you are offering a counter proposal to are draft-ietf-lamps-key-attestation-ext-00 and draft-ounsworth-pkix-key-attestation-02. These are really two different things and it is not obviously clear how this obviates both. The former has expired and, as a co-author, I am not aware of any plans to continue with it. More generally, I think a specification is needed to address conveyance of key attestations to RAs/CAs but I don't like the idea of defining a key attestation format in the same spec. These should be separate specs, in my opinion, but I'd expect the conveyance spec to support any format spec.

Yes, those were the two. And yes there needs to be a "HSM Key Attestation Statement Creation and Verification" document separate from what I wrote.

[CW] If this is not a counter proposal for the key attestation format draft, I'd drop this verbiage. It seems like it’s less of a counterproposal and more of just another attestation statement format.

Third paragraph

- This spec supports a blob (possibly containing a blob and type) and a signature. I suppose this can be viewed as "any type of certificate imaginable" but it's just a signature and some data. I'd drop this verbiage.

What you wrote isn't what that paragraph actually says.  I put it there because some folk have never seen a digital certificate that wasn't an X.509 certificate and it was important that they didn't read "certificate" as "only X.509 certificates".  It could be something that is an ASN1 SIGNED type, or it could be something that's a flat encoding similar to  Card Verifiable Certificates or CVCs - (one specification is used in passports and other travel documents) or for a zigbee implicit certificate.

The distinction between a signed object and a certificate is that a certificate always includes a public key bound by the signature, a signed object unless it is also a certificate need not include a public key.

[CW] OK. Adding more prose re: the goal of supporting !X.509 certificates as the draft is made more complete would be a good thing.


Section 2.2

- I think this section aims to serve as an alternative to draft-ounsworth-pkix-key-attestation-02. That should be made clear if so. The spec also includes a third significant unstated goal, i.e., defining new means to convey public keys to verify signed data. It's not clear to me that we need/want alternative certificate types in a spec that in its simplest form would define how to convey key attestations to a CA.

See above.  In any event, if the relying party doesn't support the different certificate types, then the sending party is out of luck.  AFAICT, those types will be somewhat bound to the type of attestation.  But you should be aware that at least one reason for this structure was to handle one of the constructs described in the webauthn attestation definitions where the TPM encoded public key being certified needed to be carried as well as the certificate containing the attestation key.

- There is already a CertificateChoices structure in CMS (that the structure in this spec imitates but conflicts with). If this structure is needed, refashioning as an extension of CertificateChoices might make sense, i.e., by using context specific tags that don't conflict, or by simply defining a few new "certificate" types for conveyance via the other field in the existing CertificateChoices.

This is mostly a "don't care" for me.  I'd prefer what I wrote because it provides a specific non-ASN1 encoding slot, but CertificateChoices would provide the escape I think is needed.

- The Certificate field is not "more or less" an X.509 certificate. It is an X.509 certificate. I would drop this verbiage.

No "X.509 certificate" is exactly a "standard X.509 certificate" as Peter G will explain.  And the Android attestation looks like an X.509 certificate but isn't really.  But I get your point.

[CW] I don't follow (and would still drop this verbiage).

- I agree with Russ' comments re: the lack of need for typedCert and typedFlatCert (but, as noted above, think all of this could be replaced with a type and statement object).

That's not what he said - he was asking why both opaqueCert and typedFlatCert were needed when the former could be encoded as the latter.  I pointed out that it was simply for encoding efficiency.

[CW] I'm not sure what he didn't say as I attributed nothing to him. The discussion above re: a definition with an OID and a bit bucket is all I was getting at here.
If object reuse was a goal,

It really isn't.
one could simply use a degenerate SignedData object with EncapculatedContentInfo playing the role of the AttestationStatement structure above and the certificates field playing the role of your AttestCertsAttribute. Under this approach, no new structures would be needed, but we'd need words to define how existing key attestations fit (and an IANA registry for those types).

Um. No?  I think you jumped from "how do we carry an attestation in a CSR" to "what does an attestation look like".  In the definition I proposed, its perfectly OK to carry a SIGNED object as the sole component of an AttestationStatement.value.  But the idea of the construct is to not have to require the attestation engine itself (inside the secure perimeter of an HSM or Secure Element) to know anything about ASN1 and to ideally be able to quickly stuff the data from the attestation into the structure for the CSR once its in user space.

[CW] I think I see the point now. AttestStatement aims to be a standalone key attestation and a wrapper for existing or future attestation types. As before, I'd prefer those functions be separated.

- The statement "it is possible to use this field to convey a bare public key as well" is at best confusing. It invites a common issue that crops up with current attestation formats (i.e., folks sticking random binary data into field that should feature ASN.1-defined structures). I think the least you could get away with here would be an OCTET STRING that contains a bare public key. I would drop the reference to "bare public key."


Nope.  As long as you type the field, its possible to carry an EC Public Key as "SubjectPublicKeyInfo",  as  a X9.63 public point, and in a raw X Y or sign-of-y plus X format.  The latter three would get stuffed in an OCTET STRING which in turn would be better off in the TypedFlatCert structure.  TypedCert could be as simple as an OCTET STRING, but the intent here was that non-ASN1 stuff got stuffed in TypedFlatCerts.

[CW] Nope? You are listing encoding the "bare public key" as either a SubjectPublicKeyInfo or an OCTET STRING, the latter being what I suggested was minimal. I'd drop this verbiage per your "as long as you type the field" caveat.
- Re: "think compact of implicit certificates", there is no need to be abstract here. You could give draft-ietf-cose-cbor-encoded-cert-05 as a concrete example.
Yup - but as mentioned above "intentionally incomplete draft".  Also, will avoid any drafts as references to the greatest extent possible.
[CW] I'd not avoid a reference where including the references adds clarity.

Section 2.5

- Why do we want key attestations that are inextricably bound to a CSR? Most of the structure here goes away if we discount that as a goal.

How does that follow?  I don't understand why you think this is the case.  This document is defining the format for an attestation attribute (per CSR), and for an attestation statement structure to go in that attribute.  It's a pretty simple model to take that attestation statement structure and define how it goes in SCEP or CMS I would think.  Should it be done in this document?  Or leave it to the folk that have more knowledge of those to write their own short document?

[CW] OK. As noted above, AttestStatement is both a attestation statement that could stand alone from the CSR as well as a wrapper of existing key attestation types that do stand alone. I'd still prefer a type/bit bucket approach.
- There seems to be several aspects of processing this structure that will rely on external knowledge to know what to do. For example, if the signature algorithm is absent in this structure then it may be encoded inside the type field or it may just be a fixed value. The format of the type field used for signature generation/verification is also left open ended with no way for the verifier to know. Similarly, the format of ancillary data is not signaled to a relying party.

TPM Attestations are different than ATECC608 attestations are different than NXP SE050 attestations are different than Android attestations are different than Webauthn attestations.  Ultimately, the relying party needs two things - the data for the attestation and an algorithm for verifying the attestation.  The way you get from an AttestationStatement attribute to that data is highly dependent on the type of attestation, and that level of detail needs to be part of the AttestationStatement definition.  See the TPM example.  This document won't tell you how to interpret the data in each of the attestationStatement fields, it will tell you that the ATTEST-STATEMENT defintion identified by the OID will give you that info.

[CW] That one would need to reference the definition of the attestation statement type to understand the content of the value field makes sense. That you must sometimes use it to understand the sibling fields of value does not seem right to me.

- The term "attestation engine" is not defined. It may be best to use vocabulary from the RFC9334.

Fair.

There's "attester" in that document which is probably covering both the attestation engine and the owner of the attestation key I think (and

How about (and I am being pedantic here - sorry):

[CW] This part of the discussion probably belongs in RATS.

"Attestation engine:  The secure hardware and firmware used to compose and sign an attestation".

"Attestation key: Either the private key used to sign an attestation statement, or the related public key used to verify the attestation statement, depending on context"

"Attester: The entity that directs the creation of an attestation statement and who owns, controls, or is permitted to use the private attestation key"

"Ancillary attestation data:  Any optional data  provided from a source external to the attestation engine as part of the creation of an attestation statement. This could be a relying party originated nonce, a time stamp, session information or other data meant to be bound in time to the attestation statement. The format of the ancillary information is not under the control of the attestation engine, but may need to be transformed, such as by hashing, before it may be incorporated within the attestation statement processing."

"Attestation statement: The object,  any optional ancillary data incorporated during the creation of that object, and the signature over that object,  created by an attestation engine at the request of an Attester to provide evidence of a fact or set of facts within the cognizance of the attestation engine at a particular point in time."  Sometimes referred to simply as an "attestation".

"Attestation: The implicit or explicit collection of an attestation statement, an attestation key, and a chain of trust for that key."

"Key attestation:  An attestation created with respect to a particular key or key pair."

The confidence in the attestation statement is not based on the trust of the attester, but on the trust of the attestation key, and the related attestation engine.  A certificate binding the attestation key (and the certificate's associated chain of trust and root of trust), implies or states the policy or evidence used to determine the trust both for the key and the related attestation engine.  Alternately, a relying party may be configured to associate a level of trust with a pre-shared attestation key.

Section 2.6

- Why do we need a CHOICE for signature encoding?

Mostly because PKIX uses the BIT STRING construct and that's rarely a better choice than OCTET STRING.  Not wedded to this, but the fall back would be BIT STRING, not OCTET STRING.  To be honest, after the change in the ATTEST-STATEMENT (see below) was also considering making this a Type'd field so that things like the elliptic curve R/S style signature -  SEQUENCE { r INTEGER, s INTEGER } structure could be placed in it directly rather than encoding it and wrapping it in a BIT STRING.

[CW] I think this gets at the overloading of this structure. If you left this detail to whatever is inside of the value field, this spec would be cleaner.

- What does "be consistent with" mean here? Does this mean the OBJECT IDENTIFIER used to identify the structure of the value field also indicates the structure of the signature field (and/or structure of the ancillary data field)? That makes the type field less like a type identifier and more like a profile identifier that describes the type of attestation, the algorithm and the signature format.

That's already resolved - see my discussion with Russ and my last response:
ATTEST-STATEMENT ::= CLASS {
  &id                 OBJECT IDENTIFIER UNIQUE,
  &Type,                  -- NOT optional
  &algidPresent       ParamOptions DEFAULT present,
  &sigPresent         ParamOptions DEFAULT present,
  &ancillaryPresent   ParamOptions DEFAULT present,
  &sigType            SignatureChoice DEFAULT OCTET STRING

} WITH SYNTAX {
  TYPE  &Type
  IDENTIFIED BY &id
  [ALGID IS &algidPresent]
  [SIGNATURE [TYPE &sigType] IS &sigPresent]
  [ANCILLARY IS %ancillaryPresent]
}

and

MikesAttest ATTEST-STATEMENT ::= (
    TYPE OCTET STRING
     IDENTIFIED BY id-mikes-attest-attribute
     ALGID IS absent
     SIGNATURE TYPE BIT STRING IS present
     ANCILLARY IS optional
}


That "consistent with" language will come out as the signature type will be enforced by the ASN1 declaration of the attestation statement.

Section 3

- As written, I think you only need one registry, i.e., for attestation statement types. This draft defines the CSR attribute and does not contemplate peer attributes or alternative attributes. The attribute in the spec could likely be registered in an existing PKIX registry.

I'll mostly leave that up to the chairs and IANA to decide.  I assume there will be a registry for attestation types, but there is no branch under IETF control for CSR attributes AFAICT.   Looking at the various SMI Security registries, it looks like the id-aa (S/Mime attributes)  branch has been used to stuff some SCEP and CMS enrollment attribute types.  If a reasonable place can't be found, then a new registry will be needed.

Thanks for the comments!

Mike


From: Spasm <[e-mail]><mailto:[e-mail]> on behalf of Michael StJohns <[e-mail]><mailto:[e-mail]>
Date: Friday, May 5, 2023 at 3:37 PM
To: "[e-mail]"<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: [lamps] Fwd: New Version Notification for draft-stjohns-csr-attest-00.txt


FYI


-------- Forwarded Message --------
Subject:
New Version Notification for draft-stjohns-csr-attest-00.txt
Date:
Fri, 05 May 2023 12:36:19 -0700
From:
[e-mail]<mailto:[e-mail]>
To:
Michael StJohns <[e-mail]><mailto:[e-mail]>



A new version of I-D, draft-stjohns-csr-attest-00.txt
has been successfully submitted by Michael StJohns and posted to the
IETF repository.

Name: draft-stjohns-csr-attest
Revision: 00
Title: Attestation Attributes for use with Certificate Requests
Document date: 2023-05-05
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/archive/id/draft-stjohns-csr-attest-00.txt<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-stjohns-csr-attest-00.txt__;!!FJ-Y8qCqXTj2!YYotdbXXk6QbFC7ZKLnS4Tu6A8Dz1VVYRDOQsws8FIvzcKuYCniFxksNDuadxaTWjUCf0ZhCkmvAiw6uFkznio0AeEUZuwU$>
Status: https://datatracker.ietf.org/doc/draft-stjohns-csr-attest/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-stjohns-csr-attest/__;!!FJ-Y8qCqXTj2!YYotdbXXk6QbFC7ZKLnS4Tu6A8Dz1VVYRDOQsws8FIvzcKuYCniFxksNDuadxaTWjUCf0ZhCkmvAiw6uFkznio0ANim7b50$>
Html: https://www.ietf.org/archive/id/draft-stjohns-csr-attest-00.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-stjohns-csr-attest-00.html__;!!FJ-Y8qCqXTj2!YYotdbXXk6QbFC7ZKLnS4Tu6A8Dz1VVYRDOQsws8FIvzcKuYCniFxksNDuadxaTWjUCf0ZhCkmvAiw6uFkznio0Ay-QnZNI$>
Htmlized: https://datatracker.ietf.org/doc/html/draft-stjohns-csr-attest<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-stjohns-csr-attest__;!!FJ-Y8qCqXTj2!YYotdbXXk6QbFC7ZKLnS4Tu6A8Dz1VVYRDOQsws8FIvzcKuYCniFxksNDuadxaTWjUCf0ZhCkmvAiw6uFkznio0A9ZJuofg$>


Abstract:
This document describes two ASN.1 Attribute definitions that may be
used to carry key attestation data in PKCS10 certificate requests and
in other circumstances.



The IETF Secretariat
_______________________________________________ Spasm mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/spasm<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spasm__;!!FJ-Y8qCqXTj2!YYotdbXXk6QbFC7ZKLnS4Tu6A8Dz1VVYRDOQsws8FIvzcKuYCniFxksNDuadxaTWjUCf0ZhCkmvAiw6uFkznio0AiuGC73k$>


Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.